handling thread locks in callback methods

[mo...@telenor.com]

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: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org