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] > > -- 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]
