You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Wesley Acheson <we...@gmail.com> on 2010/08/23 16:11:14 UTC
How to spwan child processes.
Hi,
As far as I'm aware your not supposed to extend Thread in JEE. I've
seen similar questions on Stack Overflow where it was suggested you
may use your containers Thread pool. This sounds like a terrible idea
for portability.
So take the following example.
1 A request for something specific is made to tomcat. That specific
request needs to two actions.
2 Process the users request.
3 Notify another application over http
Now If the notification fails in step 3 the users request still needs
to process and not to error so we would like to send the notification
as a background task. This is pretty easy with Threads but we
shouldn't extend Thread according to the specifications.
Questions:
1 Should this be delegated to the container?
2 If it should be delegated to the container how would I/we achieve
this in tomcat 6.
3 If it shouldn't be delegated to the container where should I ask how
to achieve a background task, because it isn't a tomcat question.
(Disclaimer: If you really want to give me the answer I won't mind :P
)
Regards,
Wesley
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: How to spwan child processes.
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Wesley Acheson [mailto:wesley.acheson@gmail.com]
> Subject: Re: How to spwan child processes.
>
> Sorry I don't even know where the specs live. I thought I saw it on
> sun some time ago but can't find it.
I usually search by JSR number.
> If I've offended you in some way then I'm sorry.
Not at all.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: How to spwan child processes.
Posted by Wesley Acheson <we...@gmail.com>.
On Mon, Aug 23, 2010 at 6:28 PM, Caldarale, Charles R
<Ch...@unisys.com> wrote:
>> From: Wesley Acheson [mailto:wesley.acheson@gmail.com]
>> Subject: Re: How to spwan child processes.
>>
>> "Certain J2EE/JEE applications (for instance those running in EJB and
>> Web containers) must not spawn new threads; instead all work should be
>> performed on the main application threads managed by the application
>> server. When applications use the WebSphere MQ base Java API the
>> application server may not be able to distinguish between application
>> code and the WebSphere MQ base Java API code, so the worker and
>> clean-up threads described above will cause the application to be
>> non-compliant with the container specification. The WebSphere MQ JMS
>> API does not break these J2EE/JEE specifications and so should be used
>> instead."
>
> Sounds like somebody's passing the buck for a flawed design in WebSphere MQ...
>
> I'd like to see the exact spec reference for their claim of non-compliance.
>
> - Chuck
>
Sorry I don't even know where the specs live. I thought I saw it on
sun some time ago but can't find it.
Look if your saying that spawning threads is Okay thats cool, makes my
life simpler. If I've offended you in some way then I'm sorry.
Regards,
Wes
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: How to spwan child processes.
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Wesley Acheson [mailto:wesley.acheson@gmail.com]
> Subject: Re: How to spwan child processes.
>
> "Certain J2EE/JEE applications (for instance those running in EJB and
> Web containers) must not spawn new threads; instead all work should be
> performed on the main application threads managed by the application
> server. When applications use the WebSphere MQ base Java API the
> application server may not be able to distinguish between application
> code and the WebSphere MQ base Java API code, so the worker and
> clean-up threads described above will cause the application to be
> non-compliant with the container specification. The WebSphere MQ JMS
> API does not break these J2EE/JEE specifications and so should be used
> instead."
Sounds like somebody's passing the buck for a flawed design in WebSphere MQ...
I'd like to see the exact spec reference for their claim of non-compliance.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: How to spwan child processes.
Posted by Wesley Acheson <we...@gmail.com>.
On Mon, Aug 23, 2010 at 5:02 PM, Caldarale, Charles R
<Ch...@unisys.com> wrote:
>> From: Wesley Acheson [mailto:wesley.acheson@gmail.com]
>> Subject: Re: How to spwan child processes.
>>
>> Thats my point I thought new Thread() was something I couldn't
>> do (by JEE specs)
>
> I'm curious - where in any of the Java EE specs did you come across that?
Not in the specs directly, but some info here
http://www.theserverside.com/discussions/thread.tss?thread_id=44353
and here
http://www-01.ibm.com/support/docview.wss?rs=171&context=SSFKSJ&dc=DB520&uid=swg21266535&loc=en_US&cs=UTF-8&lang=en&rss=ct171websphere
"Certain J2EE/JEE applications (for instance those running in EJB and
Web containers) must not spawn new threads; instead all work should be
performed on the main application threads managed by the application
server. When applications use the WebSphere MQ base Java API the
application server may not be able to distinguish between application
code and the WebSphere MQ base Java API code, so the worker and
clean-up threads described above will cause the application to be
non-compliant with the container specification. The WebSphere MQ JMS
API does not break these J2EE/JEE specifications and so should be used
instead."
>> Questions:
>> 1 Should this be delegated to the container?
>
> Is such a capability even hinted at in the servlet spec? If no, then it's a bit difficult to delegate.
The one about delegating to the container came from here
http://stackoverflow.com/questions/212134/how-do-you-launch-multiple-threads-from-within-jee
> - Chuck
>
>
> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: How to spwan child processes.
Posted by Joseph Morgan <jo...@ignitesales.com>.
Charles... in his defense (though I'm not saying he shouldn't understand
the spec), this actually stems from a series of misunderstandings,
mostly brought on by "poser" authors, "grad and teach" college
"professors", and instructors who regurgitate slides rather than
actually knowing anything. Many a programmer has been told that
spawning your own threads cannot or should not be done in the JEE space,
when what they really mean to convey is that programmers should not try
to handle request concurrency through their own threading mechanism...
because the container already does so.
-----Original Message-----
From: Caldarale, Charles R [mailto:Chuck.Caldarale@unisys.com]
Sent: Monday, August 23, 2010 10:02 AM
To: Tomcat Users List
Subject: RE: How to spwan child processes.
> From: Wesley Acheson [mailto:wesley.acheson@gmail.com]
> Subject: Re: How to spwan child processes.
>
> Thats my point I thought new Thread() was something I couldn't
> do (by JEE specs)
I'm curious - where in any of the Java EE specs did you come across
that?
> Questions:
> 1 Should this be delegated to the container?
Is such a capability even hinted at in the servlet spec? If no, then
it's a bit difficult to delegate.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e-mail
and its attachments from all computers.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: How to spawn child processes.
Posted by André Warnier <aw...@ice-sa.com>.
Wesley Acheson wrote:
> On Mon, Aug 23, 2010 at 10:56 PM, André Warnier <aw...@ice-sa.com> wrote:
>> and can someone finally explain what "spwaning child processes" means ?
>> What are you all doing to these kids ?
>>
> I apologise about the typo and I deliberately didn't want to use the
> term Threads as I was unsure if threads should be used.
>
My question was intended as a jest, but at the same time it may be a pity if it prevents
this thread to be found in the archives when looking for "spawn" (which it does, in MarkMail).
So I took the liberty of correcting the subject of this one, hoping at least then the
thread will be found.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: How to spwan child processes.
Posted by Wesley Acheson <we...@gmail.com>.
On Mon, Aug 23, 2010 at 10:56 PM, André Warnier <aw...@ice-sa.com> wrote:
> and can someone finally explain what "spwaning child processes" means ?
> What are you all doing to these kids ?
>
I apologise about the typo and I deliberately didn't want to use the
term Threads as I was unsure if threads should be used.
Sorry,
Wes
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] How to spwan child processes.
Posted by André Warnier <aw...@ice-sa.com>.
Peter Crowther wrote:
> On 23 August 2010 21:56, André Warnier <aw...@ice-sa.com> wrote:
>
>> and can someone finally explain what "spwaning child processes" means ?
>>
>
> It's a UNIXism - a fork() call spawns a child process from a parent
> process. Not sure how much further back it goes into the deep, dark and
> slightly dank dungeon of operating system history.
>
Cambridge on-line dictionary :
spawn verb (START)
[T] to cause something new, or many new things, to grow or start suddenly
spawn verb ( EGGS )
[I] to produce eggs
I believe that both definitions apply somewhat in this case.
But, talking of dank dungeons, I was referring - in jest - to "spwan" in the thread
subject, which sounds more like some English medieval form of child (or in this case
kitten) abuse.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: How to spwan child processes.
Posted by Peter Crowther <pe...@melandra.com>.
On 23 August 2010 21:56, André Warnier <aw...@ice-sa.com> wrote:
> and can someone finally explain what "spwaning child processes" means ?
>
It's a UNIXism - a fork() call spawns a child process from a parent
process. Not sure how much further back it goes into the deep, dark and
slightly dank dungeon of operating system history.
- Peter
Re: How to spwan child processes.
Posted by André Warnier <aw...@ice-sa.com>.
and can someone finally explain what "spwaning child processes" means ?
What are you all doing to these kids ?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: How to spwan child processes.
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
All,
On 8/23/2010 11:02 AM, Caldarale, Charles R wrote:
>> From: Wesley Acheson [mailto:wesley.acheson@gmail.com]
>> Subject: Re: How to spwan child processes.
>>
>> Thats my point I thought new Thread() was something I couldn't
>> do (by JEE specs)
>
> I'm curious - where in any of the Java EE specs did you come across that?
Regardless of the presence or absence of such a requirement in any
J2EE-related specification, it doesn't change the fact that creating
your own threads inside of a server application - whether it be within
an EJB or a servlet or whatever - is risky business.
If you're not careful, you can starve your own application of resources
and open your application up to a trivially-exploitable DOS hole.
Some techniques for responsibly performing asynchronous work are:
1. Use TimerTask
2. Use Executors in java.util.concurrent
3. Use Quartz (note that some versions of Quartz have a resource leak
upon webapp shutdown)
4. Use a database/whatever as a queue and run an out-of-process
notification program (my personal favorite)
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkxyzjoACgkQ9CaO5/Lv0PDghgCfbOusWE/C+FRVrhYsXOMbobIc
T/kAniflWhvYSYgkoxq2Vq8vi+UxMr5l
=r8qO
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: How to spwan child processes.
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Wesley Acheson [mailto:wesley.acheson@gmail.com]
> Subject: Re: How to spwan child processes.
>
> Thats my point I thought new Thread() was something I couldn't
> do (by JEE specs)
I'm curious - where in any of the Java EE specs did you come across that?
> Questions:
> 1 Should this be delegated to the container?
Is such a capability even hinted at in the servlet spec? If no, then it's a bit difficult to delegate.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: How to spwan child processes.
Posted by Wesley Acheson <we...@gmail.com>.
On Mon, Aug 23, 2010 at 4:27 PM, Ronald Klop <ro...@base.nl> wrote:
> class OtherAppNotifier implements Runnable {
> public void run() {
> ... doe something...
> }
> }
>
> In your servlet:
>
> doGet() {
> processUserRequest();
> new Thread(new OtherAppNotifier()).start();
> }
>
Thats my point I thought new Thread() was something I couldn't do (by JEE specs)
> You can also use java.util.TimerTask or some other threadpool thing if this
> spawns too many threads. But try the simple case first to make it working
> before optimizing it.
Yeah I've quite a few timerTasks running.
> Ronald.
>
> Op maandag, 23 augustus 2010 16:11 schreef Wesley Acheson
> <we...@gmail.com>:
>>
>> Hi,
>>
>> As far as I'm aware your not supposed to extend Thread in JEE. I've
>> seen similar questions on Stack Overflow where it was suggested you
>> may use your containers Thread pool. This sounds like a terrible idea
>> for portability.
>>
>> So take the following example.
>>
>> 1 A request for something specific is made to tomcat. That specific
>> request needs to two actions.
>> 2 Process the users request.
>> 3 Notify another application over http
>>
>> Now If the notification fails in step 3 the users request still needs
>> to process and not to error so we would like to send the notification
>> as a background task. This is pretty easy with Threads but we
>> shouldn't extend Thread according to the specifications.
>>
>> Questions:
>> 1 Should this be delegated to the container?
>> 2 If it should be delegated to the container how would I/we achieve
>> this in tomcat 6.
>> 3 If it shouldn't be delegated to the container where should I ask how
>> to achieve a background task, because it isn't a tomcat question.
>> (Disclaimer: If you really want to give me the answer I won't mind :P
>> )
>>
>> Regards,
>>
>> Wesley
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>>
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: How to spwan child processes.
Posted by Ronald Klop <ro...@base.nl>.
class OtherAppNotifier implements Runnable {
public void run() {
... doe something...
}
}
In your servlet:
doGet() {
processUserRequest();
new Thread(new OtherAppNotifier()).start();
}
You can also use java.util.TimerTask or some other threadpool thing if this spawns too many threads. But try the simple case first to make it working before optimizing it.
Ronald.
Op maandag, 23 augustus 2010 16:11 schreef Wesley Acheson <we...@gmail.com>:
>
>
> Hi,
>
> As far as I'm aware your not supposed to extend Thread in JEE. I've
> seen similar questions on Stack Overflow where it was suggested you
> may use your containers Thread pool. This sounds like a terrible idea
> for portability.
>
> So take the following example.
>
> 1 A request for something specific is made to tomcat. That specific
> request needs to two actions.
> 2 Process the users request.
> 3 Notify another application over http
>
> Now If the notification fails in step 3 the users request still needs
> to process and not to error so we would like to send the notification
> as a background task. This is pretty easy with Threads but we
> shouldn't extend Thread according to the specifications.
>
> Questions:
> 1 Should this be delegated to the container?
> 2 If it should be delegated to the container how would I/we achieve
> this in tomcat 6.
> 3 If it shouldn't be delegated to the container where should I ask how
> to achieve a background task, because it isn't a tomcat question.
> (Disclaimer: If you really want to give me the answer I won't mind :P
> )
>
> Regards,
>
> Wesley
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
>
>