struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Hill <andrew.david.h...@gridnode.com>
Subject Re: [OT]Threads and Servlets Question
Date Tue, 07 Dec 2004 05:16:54 GMT
<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 <yves.sy@gmail.com> 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, jeff_caswell@bcbstx.com
>>>>>
>>>>>
>>>>> <jeff_caswell@bcbstx.com> 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"
>>>>>>                     <jbarrows@sssc.co        To:       "Struts

>>>>>> Users Mailing List" <user@struts.apache.org>,
>>>>>>                     m>                        
>>>>>> admin@revoltingdigits.com
>>>>>>                                              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:nihilism@gmail.com]
>>>>>>> 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 <nihilism@gmail.com>
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
>>>>>>>
>>>>>>>
>>>>>>> <jbarrows@sssc.com> 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: user-unsubscribe@struts.apache.org
>>>>>>>>> For additional commands, e-mail: user-help@struts.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> -- 
>>>>>>>> http://www.revoltingdigits.com
>>>>>>>> https://jestate.dev.java.net
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> -- 
>>>>>>> http://www.revoltingdigits.com
>>>>>>> https://jestate.dev.java.net
>>>>>>>
>>>>>>> ---------------------------------------------------------------------

>>>>>>>
>>>>>>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>>>>>>> For additional commands, e-mail: user-help@struts.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>>>>>> For additional commands, e-mail: user-help@struts.apache.org
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------

>>>>>>
>>>>>> **********
>>>>>> 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: user-unsubscribe@struts.apache.org
>>>>>> For additional commands, e-mail: user-help@struts.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> -- 
>>>>> 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: user-unsubscribe@struts.apache.org
>>>>> For additional commands, e-mail: user-help@struts.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>
>>>
>>>
>>>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>>>> For additional commands, e-mail: user-help@struts.apache.org
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: user-help@struts.apache.org
>>>
>>>
>>
>>
>>
>>
>>
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


Mime
View raw message