Interesting! Thanks. Jack
On Tue, 07 Dec 2004 01:15:13 -0500, Erik Weber <[EMAIL PROTECTED]> wrote: > This is covered by JMX. For example, see javax.management.timer.Timer > (which can be initialized/destroyed by a ServletContextListener). The > idea is that you can schedule asynchronous operations but leave the > Threads to be managed by the server. > > JBoss supports this but I haven't had any luck determining if Tomcat has > any support in this area. WebLogic appears to have superior support in > this area. > > Erik > > > > > Andrew Hill wrote: > > > <snip> > > DON'T spawn threads inside a servlet container unless you really, REALLY > > have to. It'll tend to save you headaches more times than not. But if > > you gotta do it, do it with care :) > > </snip> > > > > Or as they say "dont try this at home kids" :-) > > > > <snip> > > a policy that prohibits them. (For example, > > if I was running an ISP hosting service, that's something I would > > almost certainly restrict.) > > <snip> > > That's an excellent point... especially for someone developing an app > > that they intend to deploy to a shared environment > > </snip> > > </snip> > > > > Which leads me to wonder how one does scheduled jobs in such an > > environment? Would this be a technique that is specific to the host in > > question? > > > > > > Frank W. Zammetti wrote: > > > >> Craig McClanahan wrote: > >> > >>> You might be thinking of the J2EE platform spec, which identifies some > >>> of the issues with threads in EJB containers, or when you're trying to > >>> use transactions. The servlet spec describes a bunch of things that > >>> are either likely to or guaranteed to not work when you deal with > >>> multiple threads in the context of a single request. > >> > >> > >> > >> That sounds like it, but I'm admittedly working from fuzzy > >> half-memories... reading the big specs isn't something I tend to do > >> as a hobby :) > >> > >>> It is. Who ever said that "popular" and "a good idea" were always > >>> synoymous? :-) > >> > >> > >> > >> Certainly not me :) > >> > >>> It's also the case that a very large number of webapps are installed > >>> on standalone servlet containers like Tomcat, which don't enforce the > >>> "no threads" restriction unless you configure them to run a security > >>> manager, and then provide a policy that prohibits them. (For example, > >>> if I was running an ISP hosting service, that's something I would > >>> almost certainly restrict.) > >> > >> > >> > >> That's an excellent point... especially for someone developing an app > >> that they intend to deploy to a shared environment, they definitely > >> want to keep this in mind. > >> > >>> Just out of curiousity, how do ensure that the threads are ever shut > >>> down correctly? > >> > >> > >> > >> I frankly don't. Because of the nature of these threads, they can die > >> inelegantly with no problem (unless the server goes down WHILE they > >> are processing, but I'm sure that's true of any thread). They are > >> like scheduled tasks really, one fires once a day, on fires once an > >> hour, etc. But because they make use of a lot of business logic from > >> the app, logic that isn't exposed any other way, making them daemon > >> threads made sense (we also get to use the connection pool already > >> established for the app, and some other minor resources that only > >> exist when the app is running). These threads don't service requests > >> in any way, they do periodic processing (one ages records according > >> to some complex business rules, another re-sends non-time-critical > >> asynchronous messages to a mainframe-based system if the message had > >> previously failed, things like that). > >> > >>> Are there any controls to ensure that other parts of > >>> your app won't hang forever waiting for a response from such a thread? > >>> Are there any places where you pass in a servlet request or session > >>> object to another thread (even as a parameter to a method that returns > >>> synchronously)? Are you assuming that you can propogate transaction > >>> context across threads (most implementations use a thread local > >>> variable to store this context, so passing a message to a new thread > >>> will typically *not* have the same transaction privileges as the old > >>> one). > >> > >> > >> > >> As per my last comment, they aren't servicing requests, so these > >> points don't apply in this particular case. Good points to be sure > >> though. > >> > >>> If you're not having any of those problems, you're probably fine ... > >>> that's only the things to watch out for I thought of in the time it > >>> took me to type the paragraph (there's undoubtedly a bunch more). > >> > >> > >> > >> Isn't there always with threading? :) Anyone that has done anything > >> even remotely non-trivial with threads has inevitably run into > >> troubles at some point, it's just the nature of the beast. > >> > >>> Threads are a powerful problem solving technique, for the right kinds > >>> of problems. It's just that the exercise of power also comes with > >>> associated responsibility to understand what you're doing, and what > >>> you shouldn't do, with your powers :-). > >> > >> > >> > >> Yes, what he said! :) > >> > >> >>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 :) ) > >>>> > >>> > >>> > >>> There isn't going to be universally applicabe answers to that question > >>> -- it's going to depend a lot on things like whether you're running in > >>> a container that supports this (some containers might support > >>> appication-spawned threads as a value-add feature with extra help to > >>> avoid or solve some of teh problems), what your use case is, what else > >>> is going on in the same container, what your security policies are, > >>> how skilled your developers are, ... > >>> > >>> It's hard to give relevant general answers on a question like this. > >>> > >>> But I would tend to worry less when the number of users is small, the > >>> amount of available CPU and memory is large, and your developers have > >>> done some basic study on threading and/or you have somebody who > >>> understands this stuff doing code reviews. > >> > >> > >> > >> Of all those, the skill of the developer tends to matter most > >> (assuming us architects haven't speced out something ridiculous that > >> is). At least, that's been my experience. > >> > >> I agree that a general answer to this question is near impossible, > >> but I'll take a stab at in anyway... > >> > >> DON'T spawn threads inside a servlet container unless you really, > >> REALLY have to. It'll tend to save you headaches more times than not. > >> But if you gotta do it, do it with care :) > >> > >> (Am I the King of simplistic double-talk or what?!?) > >> > >> Frank W. Zammetti > >> Founder and Chief Software Architect > >> Omnytex Technologies > >> http://www.omnytex.com > >> > >>> 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] > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- "You can't wake a person who is pretending to be asleep." ~Native Proverb~ "Each man is good in His sight. It is not necessary for eagles to be crows." ~Hunkesni (Sitting Bull), Hunkpapa Sioux~ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
