"High volume Web sites often require asynchronous or threaded operations to achieve target performance criteria. While threads in Web containers are considered bad practice, the alternative is for developers to make blocking calls to code they cannot control. It becomes important that dependencies of this nature fail-fast."
For the full article, please visit : http://www-106.ibm.com/developerworks/web/library/wa-shortcir
-
Increase stability and responsiveness by short-circuiting code (7 messages)
- Posted by: Rodolfo de Paula
- Posted on: October 21 2004 15:13 EDT
Threaded Messages (7)
- not sure about this by Mike Stover on November 03 2004 10:30 EST
- Increase stability and responsiveness by short-circuiting code by Timur Evdokimov on November 03 2004 11:30 EST
- Increase stability and responsiveness by short-circuiting code by han theman on November 03 2004 12:05 EST
- Increase stability and responsiveness by short-circuiting code by Horia Muntean on November 03 2004 16:36 EST
- This actually works (in some cases) by Erik van Oosten on November 04 2004 09:05 EST
- Better libraries needed... by Charles Bear on November 04 2004 14:22 EST
- Increase stability and responsiveness by short-circuiting code by Billy Newport on November 04 2004 16:11 EST
-
not sure about this[ Go to top ]
- Posted by: Mike Stover
- Posted on: November 03 2004 10:30 EST
- in response to Rodolfo de Paula
In a web app, spawning a thread for every request (beyond the thread the container created for the request) seems like a real bad idea. It may guarantee no user has to wait for a response too long, but it may also cause more requests to fail than otherwise would.
For new ideas, I'd prefer to look in the direction of using fewer threads, as in SEDA, and staging patterns. -
Increase stability and responsiveness by short-circuiting code[ Go to top ]
- Posted by: Timur Evdokimov
- Posted on: November 03 2004 11:30 EST
- in response to Rodolfo de Paula
"make blocking calls to code they cannot control"
I think this is what JMS is good at. If the time of request execution is not known and potentially very long, submit request for processing in the queue. This approach requires indeed some additional development to treat timeouts gracefully as well as to manage state of user session.
At least 100% J2EE compatible, no threads, no blocks. Also it seems like exactly what happens when you use flight reservation system e.g. to check availability and a huge mainframe is queried somewhere behind the scenes. -
Increase stability and responsiveness by short-circuiting code[ Go to top ]
- Posted by: han theman
- Posted on: November 03 2004 12:05 EST
- in response to Rodolfo de Paula
High volume Web sites often require asynchronous or threaded operations to achieve target performance criteria
So does high volume enterprise application. Alas, no such pattern is even allowed by the EJB standard.
Bummer. -
Increase stability and responsiveness by short-circuiting code[ Go to top ]
- Posted by: Horia Muntean
- Posted on: November 03 2004 16:36 EST
- in response to Rodolfo de Paula
How does this pattern behave if "br.readLine()" encounters a network contention situation? Or maybe a CPU overload? I don't think it will work as expected.
This pattern can be applied only where the calls are made to code that you CAN control. Elsewhere, ony real time VMs are appropiate.
Regards,
Horia -
This actually works (in some cases)[ Go to top ]
- Posted by: Erik van Oosten
- Posted on: November 04 2004 09:05 EST
- in response to Horia Muntean
I have used this approach for a task that would use up to 10 threads. However, this was not in a J2EE application server. In my solution the threads also regularly updated a float (0.0 up to 1.0) to report progress. A continuously reloading page presented this as a percentage.
As the article says, you have to be very carefull when you use this approach; threads that lock up are not removed.
Java5 contains a lot of new interfaces for managing task/thread execution. Would be interesting to see how these relate. -
Better libraries needed...[ Go to top ]
- Posted by: Charles Bear
- Posted on: November 04 2004 14:22 EST
- in response to Rodolfo de Paula
I think one thing that would help is better (more complex, yet more flexible) library design. If you had an asynchronous library available to use and didn't have to spawn a thread, the time taken in your routine would be reduced to the amount of time of the longest asynchronous call. They could all be short-circuited in parallel using the pattern described here too, perhaps, but good libraries (especially for network calls) allow a timeout to be specified directly.
I know in the .NET world web services can be invoked asynchronously, and this is really useful. Never saw this feature in the Java Web Services libraries, but it might have been added since the last time I looked - it seems like a cinch to include.
Fortunately, with the 1.4 release of Java, solid asynchronous IO is available, but its use is not so extensive yet.
For the record, it IS fine to use threads that you spawn, if you follow some basic rules, mainly that you have to make bean method calls if you want managed access to container resouces. So you can have a thread that manages a bunch of async calls and invokes a bean method to handle the result. -
Increase stability and responsiveness by short-circuiting code[ Go to top ]
- Posted by: Billy Newport
- Posted on: November 04 2004 16:11 EST
- in response to Rodolfo de Paula
WebSphere has full application controlled threading with the async beans features. A subset of this is now a standard in the commonj implementation which should be in the next versions of WebLogic and WebSphere.
Billy (IBM)