Multiple threads in XSP - Am I asking for trouble????

["Lock, Fred" <fl...@gohealthcast.com>]

I've created an XSP that creates multiple threads to do it's work.
Essentially, it simultaneously searches for information on four separate
mainframe sessions. It seems to work well. However, I haven't done any load
testing. I wonder if XSP's creating multiple threads is just asking for
trouble? Anyone have any experiences to share? Is there anything in the
architecture of Cocoon, XSP, Tomcat, etc. that makes this a bad idea?

Thanks.

Fred

Re: Multiple threads in XSP - Am I asking for trouble????

[Berin Loritsch <bl...@infoplanning.com>]

"Lock, Fred" wrote:
> 
> I've created an XSP that creates multiple threads to do it's work.
> Essentially, it simultaneously searches for information on four separate
> mainframe sessions. It seems to work well. However, I haven't done any load
> testing. I wonder if XSP's creating multiple threads is just asking for
> trouble? Anyone have any experiences to share? Is there anything in the
> architecture of Cocoon, XSP, Tomcat, etc. that makes this a bad idea?

Anytime you introduce threading like that within a high transaction environment
like a web server, you run the risk of over burdening the JVM.  Still with
Servlet-2.2, you are guaranteed one instance of your Servlet (Cocoon), but
not one instance of a thread.  If your XSP has the same four threads that it
uses for the searches, then it should be OK--but if it creates them fresh
for every request you are asking for trouble.

If your servlet engine or web server creates a new thread (or uses a pooled
thread) for each request, you run the risk of killing the server under high
load.  Consider the example that you have 250 simultaneous requests and the
server uses one thread for each request (250 threads is still reasonable).
If your XSP creates 4 threads for each request that makes a total of 1250
threads during that period (1000 from your XSP and 250 from the server).  You
are now trying to kill your machine.

If you simply have four threads that are used for _all_ requests, then you
have a much better chance of not oversaturating your server (i.e. in the
above example using this approach you would have 254 threads).

Just like XML, multithreading is not a panacea--but it can make things happen
much quicker.

Also keep in mind that your XSP code would technically not be allowed in
a J2EE environment because all threads have to be created and controlled
by the Server.  With some API changes in JDK1.3 you can expect that to
change in the future, but how soon depends on adoption of JDK 1.3.