tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject handling thread locks in callback methods
Date Mon, 03 Mar 2003 09:30:27 GMT
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?



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message