> Inspektr inability to insert records causing actions undertaken as part of > Spring Web Flow conversations to hang (causing subsequent requests to access > those conversations to wait on the lock for the conversation, thereby tying > up Tomcat request processing threads out to exhaustion and thereby causing > the CAS server to become nonresponsive) is an interesting hypothesis.
And I think you've ruled it out by pointing out that the write is driven by Executors.newSingleThreadExecutor(). Even if the writing thread were to die abnormally as you noted, the new replacement thread would be allocated from a thread pool separate from the Tomcat connector thread pool. > Is the hypothesis that these threads terminate abnormally without returning > their database connection to the pool? I believe there are cases in the JVM where threads can terminate in such a way that a finally block associated with code executing in a catch block will not be executed on termination. This could create a resource leak condition such as connection pool exhaustion in our case. There would be clear evidence of this condition in the logs; I'm certain it would be logged for com.mchange.v2 at DEBUG and other connection pool libraries are likely similar. You should turn up logging on your pooling library and monitor if you have any suspicion about that case, but I think the likelihood is approaching zero. Frankly I think it's a red herring attempting to associate SWF conversation locks with database and threading matters. I believe some SWF code review is in order as a next step, but honestly I don't think there's enough evidence to justify it at present. At the next report I'll be happy to dive in. If there are any other occurrences of this problem that haven't been reported, please speak up. M -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
