A fair few libraries one might use in ones projects also do stuff with threads internally (I believe JasperReports is an example). I recall reading a thread (no pun intended) in the JR forum suggesting that it was best to invoke reports in the servlet container rather than down in the ejb container for such reasons.
[http://sourceforge.net/forum/forum.php?thread_id=1125655&forum_id=113529]
Being able to run batch jobs without having to rely on some external application or OS thing like cron or windows scheduler is an important requirement that seems to me only possible by using threads. (Especially if the schedule has to come from logic or settings internal to the application). One would only want the scheduler to be going when the app (or rather its container) is running, and to shut down at the same time. In one of my projects I start a thread in a Plugin for this purpose which then reads the scheduled batch jobs from the db and executes them when the time comes.
How do schedulers such as quartz do it?
From what Craig was saying , keeping a handle on the request/response objects is evil, but how about the ServletContext? (Which is rather important for doing things like getResourceAsStream()... )
Yves Sy wrote:
I would think that, reading from all the responses in this thread, creating multiple threads inside a servlet container is NOT a bad thing as long as the developer takes care of business properly -- in the same way that C++ developers take care to clean up to prevent memory leaks.
Regards, -Yves-
On Mon, 06 Dec 2004 22:12:35 -0500, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
Interesting answer Craig...
I'm sure we've all heard the admonishment that we should not spawn threads inside a servlet container, the container should be "handling all threading issues". In fact, I think I even remember something about it in the spec, or at least being told there was something about it in the spec :)
I've always felt that "rule" was a bit ambiguous, to say the least...
I agree that the solution outlined here is the typical pattern, but if for no other reason than to foster debate on a potentially interesting point, why isn't this contrary to that usual bit of advice about threading?
The same question arises with daemon threads. For instance I have one app that does some periodic processing, and for various reasons it made the most sense for it to be tied to the app instance. So, when the app starts up, I spawn a couple of daemon threads, set them to low priority, and they do their thing every few hours. I've been told this is also a Bad Thing(tm) within a servlet container, but I've always felt it really wasn't. Certainly I've observed no ill effects to do such a thing.
What I'm really getting to here, and I suspect it would be for the benefit of a great many people reading this, is the simple question, what is actually OK to do with threads in a servlet container and what isn't? Perhaps more importantly, what is the reasoning behind the answers? Any thoughts? (not necessarily just from Craig :) )
-- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com
Craig McClanahan wrote:
You're using the typical pattern for this use case (although it's also feasible you could use something like JMS to accomplish the asynchronicity). The most important thing to do, though, is to ensure that you eventually kill the thread no matter what actually happens, so that you don't have something needlessly consuming resources for the remainder of the lifetime of your server instance.
Craig
On Tue, 7 Dec 2004 10:50:06 +0800, Yves Sy <[EMAIL PROTECTED]> wrote:
Here's a follow-up question:
I remember creating a thread in one of my Action classes because I needed to show a "Wait while your request is being processed..." page.
The flow goes something like: 1. the MAIN thread returns an ActionForward right away that contains the "processing" page; 2. the NEW thread I created goes ahead and makes the back-end call that takes a considerable amount of time to process; 3. After NEW thread returns with the results, it sets a flag in the session that it's done with the processing; 4. Meanwhile, the processing page keeps refreshing itself and sending execution to an action which checks for the session flag set in #3; 5. When it finally finds the session flag, it forwards to the results page.
Its working fine for me. No weird behavior on Weblogic or SAP WAS. Although now I'm curious: Is there a better way to approach this problem?
Regards, -Yves-
On Mon, 6 Dec 2004 15:03:09 -0600, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
As has been noted by others, JMS would be the better solution for an asynchronous 'process'.
But, if you have to use threads then it is probably a better approach to create a thread pool at appliction initialization and have the actions use those threads via a common synchronized data structure (hidden behind an interface).
Ensure that you have a good unique context for correlating the request and response (not to be confused with the http req/resp)
depending upon the volume of traffic you should be able to get away with a small number of threads. The actual count can be controlled via an extenal property.
good luck.
JC
"Jim Barrows" <[EMAIL PROTECTED] To: "Struts Users Mailing List" <[EMAIL PROTECTED]>, m> [EMAIL PROTECTED] cc: 12/06/2004 02:52 Subject: RE: [OT]Threads and Servlets Question
PM Please respond to "Struts Users Mailing List"
-----Original Message----- From: bryan [mailto:[EMAIL PROTECTED] Sent: Monday, December 06, 2004 1:15 PM To: Struts Users Mailing List Subject: Re: [OT]Threads and Servlets Question
threads are also a finite resource ( particularly on Linux ).
--b
On Mon, 6 Dec 2004 21:13:57 +0100, bryan <[EMAIL PROTECTED]> wrote:
because you should use a message driven bean to do
something like that.
--b
If the brass monkeys upstairs would let me, I would. However, they won't, and I've used up all of my "oops I did it anyway" cards for a while. So, while helpful, doesn't really answer my question.
As for a finite resource...... as someone else said so is memory, disk space, CPU, etc etc. As for being on linux.... I've done some pretty nasty multi-threading, in java, on linux and haven't hit that ceiling yet... ymmmv.
On Mon, 6 Dec 2004 11:48:15 -0700, Jim Barrows
<[EMAIL PROTECTED]> wrote:
Okay... I know I've read this somewhere, but can't remember. Why is it recommended you NOT start a thread inside a
servlet, which would translate to "Why is it a bad idea to start a thread inside an action?".
And, can you point me at some documentation?
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- http://www.revoltingdigits.com https://jestate.dev.java.net
-- http://www.revoltingdigits.com https://jestate.dev.java.net
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
------------------------------------------------------------------------------ ********** The information contained in this communication is confidential, private, proprietary, or otherwise privileged and is intended only for the use of the addressee. Unauthorized use, disclosure, distribution or copying is strictly prohibited and may be unlawful. If you have received this communication in error, please notify the sender immediately at (312)653-6000 in Illinois; (972)766-6900 in Texas; or (800)835-8699 in New Mexico. ********** ==============================================================================
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- A bus station is where a bus stops. A train station is where a train stops. On my desk I have a work station...
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
