https://issues.apache.org/bugzilla/show_bug.cgi?id=57172
Mark Thomas <ma...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|INVALID |---
Severity|normal |enhancement
--- Comment #3 from Mark Thomas <ma...@apache.org> ---
The INVALID response was more aimed at the suggestion that the correct way to
handle this would be a check for null. Whatever the root cause, that would
simply hide the symptom rather than fix the problem which is never a good idea.
The ISE is a much better idea although I'd change the wording since it is the
state of the web application class loader rather than the application that is
the primary concern. Better still, would be to include a check of that state as
well just in case someone manages to trigger this via some other route.
First you say this happened without the web application being stopped. Then you
say it happened after a redploy (which includes a stop followed by a start). I
guess you mean the problem happened after the web app was redeployed but while
that redployed web application was running. That would be consistent with the
reported symptoms.
Yes I do consider the use of a ThreadLocal that exists outside the scope of a
single web application without being cleaned up when that application stops a
memory leak. The Servlet spec is (currently) silent on the use of ThreadLocals
and on thread pools being shared across multiple applications. Feel free to
share you views with the Servlet EG in this issue:
https://java.net/jira/browse/SERVLET_SPEC-82
Personally I am in favour of a single thread pool. Partly for efficiency,
partly for performance (per application thread pools would still require a
common thread pool to handle a request until the correct web app was identified
and then hand off the request to the correct thread pool). If you really want
the isolation of per application thread pools then it is probably simpler to
just deploy each application to a separate instance.
There are alternative solutions to using ThreadLocals that may be appropriate
depending on the circumstances. For example, the SecureRandom instances Tomcat
uses to generate session IDs:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/util/SessionIdGeneratorBase.java?view=annotate
I'm re-opening this as an enhancement request for a better error message in
this case.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
