Hi Kito, On Fri, 2009-01-16 at 17:44 -0600, Kito Mann wrote: > I'm seeing the following output in the logs from Orchestra: > > org.apache.myfaces.orchestra.lib._ReentrantLock lockInterruptibly > Waited for longer than 30000 milliseconds for access to lock > org.apache.myfaces.orchestra.lib._reentrantl...@1ec61ec6 which is > locked by thread WebContainer : 0 > > I'm not convinced there is a specific problem yet, but can someone > explain under what circumstances I should expect to see this?
This is coming from Orchestra code that automatically makes sure that a single ConversationContext is accessed only by one thread at a time. When the request starts, a lock in the context is acquired. If a request is already using that context then the new request has to wait until the previous request is completed. So this kind of message can occur when a view takes longer than 30 seconds to process, and then the same user tries to trigger a concurrent access (eg is impatient and clicks on a submit button again). If that's the situation in which you see this message, then all is ok. If you see this in simple quickly-rendered pages, then there is definitely a problem somewhere. I do remember that there was a bug with Orchestra's locking code that was fixed a while ago. The fix is definitely in the latest release though - I presume you're using version 1.3. The name of the thread that has the lock is "WebContainer: 0", which looks a bit odd to me. Which servlet engine is this? I'm sure Tomcat does not name its threads like this. Are you still experimenting with WebSphere? I suppose it might give its "request handling" threads such a name, but it looks more like some kind of special thread instead. It could be useful to log the thread id for ordinary requests (eg just change the log4j message format string) and see if "WebContainer:0" really is a normal request-handling thread. If not, it would be useful to know what else that thread does... Regards, Simon
