loadLibrary / call a native method from an EJB

[Thorsten Schiller]

Hi,

I've tried to call a method, written in C++, which resides in a dll, to call
from an EJB.
I guess the dll was loaded, because I cannot delete the dll (native.dll),
after an EJB-method call, which is an effect of the following code within
the EJB:

static

System.loadLibrary("native");
}

Although the dll was loaded (probably), the native call from the EJB to the
dll causes the error:

RemoteException: java.lang.UnsatisfiedLinkError: dump

where dump is the C++ function.

Is this a security problem, i.e. are calls to native code prohibited at all?
I am using the WebLogic Server 5.1 NT.

Thanks,
Thorsten

[Jason Jonas]

Using JNI is not recomended in the app server. The biggest issue is
what happens when the native method dumps core? The entire JVM dies
and that means your middle tier (assuming you're not clustered) goes
away with a single core dump.

I've never made JNI calls from an EJB and wouldn't know if it's a
security issue. I don't think it is because you were able to load the
library and I would think the violation would occur at that time. I
would look closely at the process taken to create the lib. Did you
follow the appropriate steps?

Can these native methods be re-written in Java? Seems like that would
be the best approach. If not, consider using straight RMI objects to
handle these JNI requests. That way, if a native method bails, you
would only affect the requests being serviced by that RMI object
rather than your entire middle layer.

I've done something similar to this before. It's working quite well.
We worked with a pre-defined number of these RMI objects and
instructed them what to do via JMS (they were RMI objects for other
reasons). One thing you may want to consider is binding an RMI pool
manager into JNDI and letting the factory manage a pool of these RMI
objects - each running in their own JVM and they will register with
the pool manager when they come up. Doesn't sound too scalable, but
depending on the transaction time for these requests to native
methods, you may find that you can achieve reasonable throughput with
a small number of them.

You could also use JMS in a similar fashion to the above. Depending on
your requirements, this may be a better approach. Let some number of
JMS clients consume and process messages from a queue and send the
response (if any) using the JMSReplyTo field back to the caller -
which can be an EJB.

Of course if you're willing to live with the caveats, then carry on.

Jason

[Wei Guan]

I don't think it is a security issues. Check the PATH setup in your
environment and your startup scripts. Using JNI in EJB is not recommended.
Having a stable JNI code needs lots of efforts.

My 2 cents.

--
Cheers - Wei
Thorsten Schiller <schi...@quazar.de> wrote in message
news:8i5pkh$jmj$1...@newsgroups.bea.com...

[alex...@my-deja.com]

Thorsten--

both replies you've gotten so far are correct in telling you that JNI
is hard, but I wouldn't draw the same conclusions.

First: the most likely explanation for your problem is that you haven't
declared your method extern "C" and the name got C++-mangled. Now the
JVM is looking for a well-defined name and it's seeing some "garbage"
including "@@X5IU" or some such thing.

Second: If you're doing this more than once, you should use something
like our tool that creates C++ proxies for Java objects and would help
you incredibly. Contact me at my deja address if you want more
information,

Alex

In article <8i5pkh$jmj$1...@newsgroups.bea.com>,

"Thorsten Schiller" <schi...@quazar.de> wrote:
> Hi,
>
> I've tried to call a method, written in C++, which resides in a dll,
to call
> from an EJB.
> I guess the dll was loaded, because I cannot delete the dll
(native.dll),
> after an EJB-method call, which is an effect of the following code
within
> the EJB:
>
> static
>
> System.loadLibrary("native");
> }
>
> Although the dll was loaded (probably), the native call from the EJB
to the
> dll causes the error:
>
> RemoteException: java.lang.UnsatisfiedLinkError: dump
>
> where dump is the C++ function.
>
> Is this a security problem, i.e. are calls to native code prohibited
at all?
> I am using the WebLogic Server 5.1 NT.
>
> Thanks,
> Thorsten
>
>

Sent via Deja.com http://www.deja.com/
Before you buy.

[Bjørn Bjerkeli]

I think it is because you haven't set the SHLIB_PATH (that's the name on HP,
don't know about NT) variable, so that wls knows where to retrieve the dll (or
shared library on unix)

I agree with the follow-ups that it is probably not a good idea to use shared
libraries, it will probably work fine when load is low, but it will probably
fail in a multi user scenario because of threading or locking issues (the lib
has to be re-entrant and so on)

/Bjørn Bjerkeli

[Thorsten Schiller]

Jason,

first of all, thanks for your detailed answer.

> I've never made JNI calls from an EJB and wouldn't know if it's a
> security issue. I don't think it is because you were able to load the
> library and I would think the violation would occur at that time. I
> would look closely at the process taken to create the lib. Did you
> follow the appropriate steps?

I'm quite sure that I'm following the appropriate steps because the dll
works
in a simple Java client and the code in the EJB is limited to:

native public void dump(long v);

static
{
System.loadLibrary("native");
}

and the call of dump itself.

> Can these native methods be re-written in Java? Seems like that would
> be the best approach. If not, consider using straight RMI objects to
> handle these JNI requests. That way, if a native method bails, you
> would only affect the requests being serviced by that RMI object
> rather than your entire middle layer.

The tasks the methods performs are image processing
(compression, decompression, scaling, ...). Java is much too slow for such tasks.
However, I like your idea to use RMI objects as a wrapper for the native methods.

> I've done something similar to this before. It's working quite well.
> We worked with a pre-defined number of these RMI objects and
> instructed them what to do via JMS (they were RMI objects for other
> reasons). One thing you may want to consider is binding an RMI pool
> manager into JNDI and letting the factory manage a pool of these RMI
> objects - each running in their own JVM and they will register with
> the pool manager when they come up. Doesn't sound too scalable, but
> depending on the transaction time for these requests to native
> methods, you may find that you can achieve reasonable throughput with
> a small number of them.

RMI pool and one JVM per object, this sounds good as well.
Concerning scalability, we don't expect more than 100-200 concurrent
clients, but many of them will invoke image processing routines.

> You could also use JMS in a similar fashion to the above. Depending on
> your requirements, this may be a better approach. Let some number of
> JMS clients consume and process messages from a queue and send the
> response (if any) using the JMSReplyTo field back to the caller -
> which can be an EJB.

I'm not familiar with JMS, but I guess that it is asynchronous and that
might
be helpful sometimes, i.e. because of the time consuming image processing
tasks.

> Of course if you're willing to live with the caveats, then carry on.

Maybe, I would, if I would know how; but I think it is not necessary. :)

> Jason

Thanks again,
Thorsten

[Jason Jonas]

The only thing I can think of that may be different between a
stand-alone client JVM loading a lib and a WL JVM not being able to is
the environment. Wei mentioned this in a post. Does the path env var
contain the directory where this native lib lives in both
environments? Nothing else comes to mind. Sorry.

Taking a JMS approach has advantages. Each client could create a temp
queue. If the image processing requests need to be massaged or
augmented with other information, an EJB could perform this additional
processing. Then, the request could be sent to a queue that's
monitored by some number of JMS clients that process the image and
send the reply directly back to the client's queue. The client could
then handle the reply in a synchronous or asynchronous manner. The
good thing here is that if the request doesn't need to be 'massaged',
the clients can make the request directly to the image processors by
producing and sending the request directly to them. I think this is
the approach I would take. It's elegant and totally isolates the
middle layer from the caveats of using native libraries.

I can't remember, but I think there's a way to spawn/decay additional
queue consumers. Hmmm... That would be a good way to have your image
processors scale. Of course, I could just be smoking something too.
It's worth looking into. Have fun.

Jason

[Thorsten Schiller]

Hhhmmm, I still think that it is not an environment problem, because the dll
was loaded,
remember, I cannot delete it.
I've just made one more test: I renamed the dll and indeed the error is now:
java.lang.UnsatisfiedLinkError: no native in java.library.path
instead of:
java.lang.UnsatisfiedLinkError: dump

Hhmm, maybe it is a name resolution problem (method name).
WebLogic does not came with its own javah, so I used the one from my JDK.
My JDK is version 1.3 and I use also the JRE 1.3 for my testclient,
but WebLogic comes with its own JRE and that is V1.2.
So, my testclient (which can succesfully invoke the method) runs under JRE
V1.2
and my EJB runs under JRE V1.2.

However, if no one have an idea, I will track the problem on the side,
because the considerations of Jason are the better way anyway.

Thanks for your comments,
Thorsten

[Thorsten Schiller]

Of course, I want to say V1.3 versus V1.2, instead of V1.2 versus V1.2 :)

So, my testclient (which can succesfully invoke the method) runs under JRE

V1.3

and my EJB runs under JRE V1.2.

Thorsten Schiller <schi...@quazar.de> schrieb in im Newsbeitrag:
8iau4t$eni$1...@newsgroups.bea.com...

[Jason Jonas]

Have you tried running WL under 1.3? The easiest way to test would be
to start WL by using the startweblogic.cmd file from a command window.
I typically REM out the JAVA_HOME check/set steps and add a single set
command. For instance:

set JAVA_HOME=d:\java\jdk1.2.2

Maybe, just maybe...

Jason

[Thorsten Schiller]

I have checked it out, the native call fails under JRE V1.3 as well.

Thorsten

[alex...@my-deja.com]

Have you checked out the method naming? What is the exported methodname
as reported by the map file or dumpbin?

Most unsatisfied link errors in C++ are due to name mangling. Another
frequent problem is the environment. You might be picking up an older
development version of the DLL that does not export the correct method
even if the current version does.

Alex

In article <8idl31$sso$1...@newsgroups.bea.com>,

"Thorsten Schiller" <schi...@quazar.de> wrote:
> I have checked it out, the native call fails under JRE V1.3 as well.
>
> Thorsten
>
>