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]
-- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
