When a web application developer implements an event listener interface, e.g., the
HttpSessionBindingListener interface, the corresponding callback method essentially
becomes part of the internal Tomcat workings. A thread lock in the callback method is
in fact a thread lock in Tomcat itself. Unlike thread locks occurring in the
request-processing servlet code, this type of thread lock can obviously affect all
users/sessions of the web application.
We had a case where the HttpSessionBindingListener.valueUnbound callback method, which
is called by the background thread that checks for session timeouts in
org.apache.catalina.session.StandardManager, occationally got into a thread lock
situation (caused by a blocking read() on a socket connection).
This caused the background thread in StandardManager to hang, and hence the session
timeout mechanism of the container stopped working for this web application. Obviously
not a good situation in a production setting with a lot of sessions.
Is the proper way to handle this problem simply to ask developers to be especially
careful when programming such callback methods? Or could Tomcat be made more robust
when encountering such situations? Should a problem in the web application code cause
the servlet container to stop working as intended?
Regards,
Morten.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
