servlet+thread+jni

[stef]

Hello guys,

I would like to call native shared libraries in my servlet/jsp page.

So -As I know- servlets are multi-threaded. It means (I suppose) that my
native libraries have to be safe-threaded too no ?
(inside I call several time some C modules (like Sybase 11.9 or old version
of lex & yacc) which are no thread-safe !

Am I wrong or I'm in front of a "big" problem ?

Do you have some experiences in this case ?

Help me please

Thanx...

 

[SPG]

Hello guys,

I would like to call native shared libraries in my servlet/jsp page.

So -As I know- servlets are multi-threaded. It means (I suppose) that my
native libraries have to be safe-threaded too no ?
(inside I call several time some C modules (like Sybase 11.9 or old
version
of lex & yacc) which are no thread-safe !

Am I wrong or I'm in front of a "big" problem ?

Do you have some experiences in this case ?

Help me please

Thanx...

Hi,

Several solutions:

A) Make your servlets single threaded by default (using the config of your
web app), but his could cause you some performance issues.

B) Make all your JNI calls through a single class that you are able to
obtain a sync lock on using the "synchronized" keyword..

public class JNICaller{
public static Ovject SYNC;
static{
SYNC = new Object();
}

public native void jniCall(String aParam);

public void makeJniCall(String aParam){
syncronized(SYNC){
jniCall(aParam);
}
}

//Alternativeley..
public synchronized vois makeJniCall2(String aParam){
jniCall(aParam);
}
}

Not sure if you can make the native declaration synchronized, if so, then
that will work too.

Steve

 

[Darryl Pierce]

I would like to call native shared libraries in my servlet/jsp page.

You can't.

So -As I know- servlets are multi-threaded.

Servlets are single-threaded and cannot spawn their own threads.

 

[stef]

Hi again

Thx for the anwser

A) Make your servlets single threaded by default (using the config of your
web app), but his could cause you some

SPG, what you say, is very interesting...

What kind of action/consequence have the fact to switch servlet to single
thread ?
Does it mean java will use fork() instead (I go crazy )

Seriously. How java does to manager multi-connexion in this case ?
May be playing with synchronize() palette functions

Could U tell me more please ?


thanx

 

[SPG]

Hi again

Thx for the anwser


SPG, what you say, is very interesting...

What kind of action/consequence have the fact to switch servlet to single
thread ?
Does it mean java will use fork() instead (I go crazy )

Seriously. How java does to manager multi-connexion in this case ?
May be playing with synchronize() palette functions

Could U tell me more please ?


thanx

Stef,

If you make your servlets signle threaded, then you will (and I think I need
to consult docs to be 100% on this) create a new instance of your servlet on
each connection, hence put some extra load on the servers and could cause
you some performance. This also means one connection at a time hence all
other connections are queued... Again, causing some unwanted delays to your
users..

Another problem with making your servlet single threaded is that it only
makes the specific servlet single threaded. Shared resources will still be
vulnerable.

My suggestion is that you identify your potential critical sections of code
(IE: Where you need to make calls out via JNI ) and synchronize specifically
around these. Be careful not to over synchronize else you will hit more
performance issues.

Have a look through the java.sun.com forums and see examples there..

Steve

 

[SPG]

You can't.


Servlets are single-threaded and cannot spawn their own threads.

<snip>> Servlets are single-threaded and cannot spawn their own
threads.</snip>

Quite the contrary, Servlets by default are multi threaded, and can spawn
threads if they like... You however cannot write to the reponse once the
doGet/doPost methods have exited..

 

[castillo.bryan]

I know you are asking about threading, but I would worry about writing
a jsp or servlet which accesses JNI code written in-house. Your
threading issues could crash your entire web server. I'd probably
write a small daemon running the JNI code either using sockets directly
or RMI. You would still have the threading issue there though.

I would also, consider writing the daemon in C or C++. In C or C++ you
could fork an instance for each tcp session. Since each session would
then have its own process space, you could effectively use multiple
threads in the web server. I would also keep a pool of connections to
this server in the java space, so that the creation of processes is
done before the requests are even made. This would require the daemon
to service multiple requests per TCP session. If you used this
approach, you could even use inetd/xinetd for your daemons socket
handling. (This might be too anal or complex for your needs though.)

 

[SPG]

I know you are asking about threading, but I would worry about writing
a jsp or servlet which accesses JNI code written in-house. Your
threading issues could crash your entire web server. I'd probably
write a small daemon running the JNI code either using sockets directly
or RMI. You would still have the threading issue there though.

I would also, consider writing the daemon in C or C++. In C or C++ you
could fork an instance for each tcp session. Since each session would
then have its own process space, you could effectively use multiple
threads in the web server. I would also keep a pool of connections to
this server in the java space, so that the creation of processes is
done before the requests are even made. This would require the daemon
to service multiple requests per TCP session. If you used this
approach, you could even use inetd/xinetd for your daemons socket
handling. (This might be too anal or complex for your needs though.)

Bloody good point though!
One incorrect pointer assignment and *poof* no more JVM!
Not good for a webserver!

 

[Darryl Pierce]

Quite the contrary, Servlets by default are multi threaded, and can spawn
threads if they like... You however cannot write to the reponse once the
doGet/doPost methods have exited..

My bad. Replace "cannot" with "should not". To quote the specification:

Implementations of the request and response objects are not guaranteed
to be thread safe. This means that they should only be used within the
scope of the request handling thread. References to the request and
response objects must not be given to objects executing in other threads
as the resulting behavior may be nondeterministic.