You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by "Rainer Frey (Inxmail GmbH)" <ra...@inxmail.de> on 2009/05/06 11:58:56 UTC
Change thread name of HTTP worker threads at Runtime
Hi,
I occassionally have to analyse thread dumps of tomcat servers which serve up
to 25 instances of the same (quite complex) web service application. All
custom threads have names that contain the instance id, but it is impossible
to see which HTTP processor threads serve which application instance.
Now we came up with the idea to rename the threads at the beginning of the
request processing (to current-name + application-id), and rename them back
totheir base name after the request is processed. As these threads are
managed by Tomcat, I am wondering: is this a bad idea? Anything in Tomcat (or
Java) that could cause a problem if we do that?
Also, is this better implemented in the servlets (almost all our relevant
requests go to servlets, the are hardly any JSP) or as a filter? Filter seems
a better idea, but I never developed one, so I might overlook some
characteristic that makes this unsuitable to do in a filter.
We want to implement this first on Tomcat 5.0, but migrate to Tomcat 6.0 later
this year. Any notable differences in this regard?
TIA for any thoughts on this.
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Change thread name of HTTP worker threads at Runtime
Posted by "Rainer Frey (Inxmail GmbH)" <ra...@inxmail.de>.
On Friday 15 May 2009 16:58:55 Caldarale, Charles R wrote:
> > From: Rainer Frey (Inxmail GmbH) [mailto:rainer.frey@inxmail.de]
> > Subject: Re: Change thread name of HTTP worker threads at Runtime
> >
> > I just read this up. It says "should ensure". How strong this is
> > sepends on whether this has RFC "SHOULD" characteristics, or is
> > merely a recommendation.
>
> It's not a recommendation, it's a requirement. The Tomcat committers are
> extremely careful about implementing the spec precisely. There's only one
> thread that processes a request from start to finish.
>
> - Chuck
Thanks for confirming. I didn't ever look at this aspect of servlet spec
before.
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Change thread name of HTTP worker threads at Runtime
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Rainer Frey (Inxmail GmbH) [mailto:rainer.frey@inxmail.de]
> Subject: Re: Change thread name of HTTP worker threads at Runtime
>
> I just read this up. It says "should ensure". How strong this is
> sepends on whether this has RFC "SHOULD" characteristics, or is
> merely a recommendation.
It's not a recommendation, it's a requirement. The Tomcat committers are extremely careful about implementing the spec precisely. There's only one thread that processes a request from start to finish.
- 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.
Re: Change thread name of HTTP worker threads at Runtime
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Rainer,
On 5/15/2009 10:47 AM, Rainer Frey (Inxmail GmbH) wrote:
> On Friday 15 May 2009 16:07:11 Christopher Schultz wrote:
>> Not likely, since Java doesn't support continuations.
>> The request handler thread should handle the request from start to finish.
>
> Is this explicitly stated somewhere?
Java simply does not have continuations, so the thread that calls, say,
Filter.doFilter must be the same thread that returns from that same
Filter.doFilter call.
> There could theoretically be a queue of
> Request/Response pairs, and different threads could pick one up, execute one
> element in the filter chain, and put the pair back for the next thread.
Er, I suppose that's technically possible but there's no reason to do
that: pipelineing an HTTP request is pretty silly, since you'd just be
adding thread management overhead to a straightforward process.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkoNjJ8ACgkQ9CaO5/Lv0PCkuQCfSsUDQvnqLv6EtP6ida/eP7oK
GxgAnAqMLCkrHvsLRyVEsYO63MWeVQVY
=mY4K
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Change thread name of HTTP worker threads at Runtime
Posted by "Rainer Frey (Inxmail GmbH)" <ra...@inxmail.de>.
On Friday 15 May 2009 16:07:11 Christopher Schultz wrote:
> Rainer,
>
> On 5/15/2009 2:37 AM, Rainer Frey (Inxmail GmbH) wrote:
> > is the assumption that one request is processed by one thread (and never
> > passed to another during processing) true for all connectors, including
> > NIO?
>
> Are you asking if the request is passed to another thread at any point
> for processing?
Exactly, in my case I'm interested in the span between entering the
application's filter chain and returning from it in the outmost filter.
> Not likely, since Java doesn't support continuations.
> The request handler thread should handle the request from start to finish.
Is this explicitly stated somewhere? There could theoretically be a queue of
Request/Response pairs, and different threads could pick one up, execute one
element in the filter chain, and put the pair back for the next thread.
> The servlet spec goes on to require (in section 8.2) that the container
> dispatches sub-requests (includes or forwards) using the same thread
> that was originally chosen to handle the primary request.
I just read this up. It says "should ensure". How strong this is sepends on
whether this has RFC "SHOULD" characteristics, or is merely a recommendation.
> I think you're safe.
I guess so too, but it's nice to hear opinions of people with insightinto
internals.
> -chris
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Change thread name of HTTP worker threads at Runtime
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Rainer,
On 5/15/2009 2:37 AM, Rainer Frey (Inxmail GmbH) wrote:
> is the assumption that one request is processed by one thread (and never
> passed to another during processing) true for all connectors, including NIO?
Are you asking if the request is passed to another thread at any point
for processing? Not likely, since Java doesn't support continuations.
The request handler thread should handle the request from start to finish.
The servlet spec goes on to require (in section 8.2) that the container
dispatches sub-requests (includes or forwards) using the same thread
that was originally chosen to handle the primary request.
I think you're safe.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkoNdw8ACgkQ9CaO5/Lv0PB3zQCfao1TcPnoNZ6nMMiIvJ7Pi7Hf
HJwAoIG9NEmyyTZX81MuOkL4uM8bin1t
=ZFJ9
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Change thread name of HTTP worker threads at Runtime
Posted by "Rainer Frey (Inxmail GmbH)" <ra...@inxmail.de>.
On Wednesday 06 May 2009 12:42:09 Ronald Klop wrote:
> Op woensdag, 6 mei 2009 11:58 schreef "Rainer Frey (Inxmail GmbH)" :>
>
> > Hi,
> >
> > I occassionally have to analyse thread dumps of tomcat servers which
> > serve up to 25 instances of the same (quite complex) web service
> > application. All custom threads have names that contain the instance id,
> > but it is impossible to see which HTTP processor threads serve which
> > application instance.
> >
> > Now we came up with the idea to rename the threads at the beginning of
> > the request processing (to current-name + application-id), and rename
> > them back totheir base name after the request is processed. As these
> > threads are managed by Tomcat, I am wondering: is this a bad idea?
> > Anything in Tomcat (or Java) that could cause a problem if we do that?
>
> At the company I work we are doing this for a couple of years already with
> Tomcat 4, 5 and now 6. Works very well. And makes threaddumps more easy to
> read.
>
> Ronald.
Thanks for confirming, I implemented this and it works fine. I wonder though:
is the assumption that one request is processed by one thread (and never
passed to another during processing) true for all connectors, including NIO?
Regards
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Change thread name of HTTP worker threads at Runtime
Posted by Ronald Klop <ro...@base.nl>.
Hi,
At the company I work we are doing this for a couple of years already with Tomcat 4, 5 and now 6. Works very well. And makes threaddumps more easy to read.
A filter is very ease to make.
public class ThreadNameFilter implements javax.servlet.Filter {
public void doFilter(ServletRequest req, ServletResponse resp, FilterChain fc) throws IOException, ServletException {
HttpServletRequest httpReq = (HttpServletRequest)req;
final Thread curThr = Thread.currentThread();
final String oldName = curThr.getName();
try {
curThr.setName(httpReq.getRequestURI());
fc.doFilter(req, resp);
} finally {
curThr.setName(oldName);
}
}
Something like this.
Ronald.
Op woensdag, 6 mei 2009 11:58 schreef "Rainer Frey (Inxmail GmbH)" :>
> Hi,
>
> I occassionally have to analyse thread dumps of tomcat servers which serve up
> to 25 instances of the same (quite complex) web service application. All
> custom threads have names that contain the instance id, but it is impossible
> to see which HTTP processor threads serve which application instance.
>
> Now we came up with the idea to rename the threads at the beginning of the
> request processing (to current-name + application-id), and rename them back
> totheir base name after the request is processed. As these threads are
> managed by Tomcat, I am wondering: is this a bad idea? Anything in Tomcat (or
> Java) that could cause a problem if we do that?
>
> Also, is this better implemented in the servlets (almost all our relevant
> requests go to servlets, the are hardly any JSP) or as a filter? Filter seems
> a better idea, but I never developed one, so I might overlook some
> characteristic that makes this unsuitable to do in a filter.
>
> We want to implement this first on Tomcat 5.0, but migrate to Tomcat 6.0 later
> this year. Any notable differences in this regard?
>
> TIA for any thoughts on this.
>
> Rainer
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
>
>