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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
