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