This forum is now a read-only archive. All commenting, posting, registration services have been turned off. Those needing community support and/or wanting to ask questions should refer to the Tag/Forum map, and to http://spring.io/questions for a curated list of stackoverflow tags that Pivotal engineers, and the community, monitor.

ERROR [btpool0-3] BaseXMLFilter.doXmlFilter(157) - Exception in the filter chain
org.springframework.web.util.NestedServletException: Request processing failed; nested exception is org.springframework.webflow.conversation.impl.LockTimeoutException: Unable to acquire conversation lock after 30 seconds
at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:583)
at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:501)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1093)
at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:154)
at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:260)
at org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:366)
at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:493)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:359)
at org.springframework.security.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:109)
at org.springframework.security.intercept.web.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:83)
...
Caused by: org.springframework.webflow.conversation.impl.LockTimeoutException: Unable to acquire conversation lock after 30 seconds
at org.springframework.webflow.conversation.impl.JdkConcurrentConversationLock.lock(JdkConcurrentConversationLock.java:44)
at org.springframework.webflow.conversation.impl.ContainedConversation.lock(ContainedConversation.java:69)
at org.springframework.webflow.execution.repository.support.ConversationBackedFlowExecutionLock.lock(ConversationBackedFlowExecutionLock.java:51)
at org.springframework.webflow.executor.FlowExecutorImpl.resumeExecution(FlowExecutorImpl.java:150)
at org.springframework.webflow.mvc.servlet.FlowHandlerAdapter.handle(FlowHandlerAdapter.java:173)
at org.springframework.webflow.mvc.servlet.FlowController.handleRequest(FlowController.java:172)
at org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(SimpleControllerHandlerAdapter.java:48)
at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:875)
at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:809)
at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:571)
...

list.xhtml (list of Persons) -> click "Edit" -> editPerson.xhtml (form containing data from selected Person) -> click "Save" -> back to list. I did that several times before it "hangs" and later on threw the exception.

Unfortunately I can't reproduce the error (tried the same case, didn't work).

Comment

SWF synchronizes on the conversation to prevent basic concurrency issues. I wasn't aware that there was a timeout when trying to acquire the lock. It seems like that would be problematic, since the lock timeout could occur before request timeout.

Comment

WebFlow uses ReentrantLock ( new in java 5 ) instead of intrinsic locking ( synchronized ) for it's locking. Using ReentrantLock.tryLock method to obtain locks allows you to set a timeout, which is what webflow uses.

I have done some digging and am still trying to find out why we are getting this issue. It looks to me that for some still unknown reason to me we are getting a deadlock on our c3p0 connection pool. This is preventing flows from resuming because no one can get a connection from the pool. Then the FlowExecutor cant resume the flow because another request has the lock waiting for a connection from the connection pool. Http requests keep coming in until too many socket are open causing a org.apache.tomcat.util.net.JIoEndpoint.unknown E Socket accept failed
java.net.SocketException: Too many open files
exception. This brings down the whole server.

Another curious and still unexplained phinomina is just before hte SocketException starts getting thrown, the dm server executes a DELETE request on our web bundle, which of course fails. It seems that the dm server is trying to prevent this one bundle from taking down to whole server, which would be great if it worked. I however have found no documentation of this.

Comment

It is configurable but admittedly it's not the easiest config setting to get at. The actual setting is on SessionBindingConversationManager, which is used by the webflow-executor tag. Unfortunately, the tag doesn't make this setting configurable. We're aware of this inconvenience at the moment and plan to address it in a future release. Would you mind opening a JIRA requesting why you need this? That always helps and ensures it doesn't get lost.

Comment

I have a problem where users can navigate away from a flow before reaching the end state. If I navigate back to the flow it seems that the persistence context keep acquiring new connection so for example if I set max connection to 10 in my DBCP configuration, after 10 times navigating away and back again to the same flow, we have a deadlock because we reach the connection pool cap.

It's also my question that how WebFlow anticipate the case where users navigate away from a flow before reaching an end state? If we use JPA, will the EntityManager acquired for the flow be closed if user navigate away from the flow? If not when will it be closed?

Thanks before,

Peter

Comment

In my case I found out that my service layer retrieves a set of entities. The service layer method was encapsulated in a transaction (using @Transactional) and whenever it is executed, Hibernate connection manager open a jdbc connection and upon method call completion release the connection to the pool. Later on, still in the same request , upon rendering, the view template retrieve a lazy loaded Many-To-One association from these entities to be presented in the view. This causes jdbc connection leak, because the lazy loaded Many-To-One association borrows a jdbc connection but somehow the jdbc connection never released/returned to the pool. Each time I get back to the view state, the lazy loaded Many-To-One association causes another jdbc connection to be opened but never released until the connection pool exhausted to its maximum active connection limit. Finally I got a deadlock.

Cheers,

Peter

Comment

We are also get this exception in our program. The reproducing is simple - if you have executing two (or more) ajax requests and one of it is processed for more than 30 second (this can be in the case of long requests for external system) - others will be timeout with this exception.

As workaround you can use request queue for ajax requests at client (and cancelling by this the first 'A' in ajax). The second way - a rewrite request handling to extract any long requests from WebFlow request cycle to another system.

Comment

I am seeing this exception in our application as well. This seems to be happening randomly in the following scenario:
We have automatic form submission logic in our form. When all the input values are valid in the form, we programatically "click" the Next button to start the form processing. But it seems that the processing is taking a while and the form is still displayed in user's browser. Then user clicks on Next button again, and this exception would occur.

What i understood from reading forums is that the locks are used to synchronize transactions in the spring webflow - e.g., if a user clicks on Next button twice, the first Next action would hold onto the lock and release after it's done. The second Next click will be processed only after the first one releases the lock.

So, my initial assessment was that when the user manually clicked the Next button, it is trying to acquire the conversation lock, which was already used by the first programmatic click of Next button, causing the timeout.
To verify the above, we modified our form processing code so that it's taking longer than 30 seconds, and make second request to see if the timeout would occur. But no luck in reproducing error.

Comment

I got the exception after I had not annotated with @Transactional several methods which were accessing the db with hibernate in read only mode; this by itself was not throwing any exception, and the data was read correctly, but it seems that the connections were not returning to the pool (c3p0, as seems to be the case also in one of the mails on this thread). So a call to a spring service method was not returning, thereby causing eventually the LockTimeoutException. Clearly, changing the lock timeout limit in this case would not help - one should instead simply annotate all methods which access the db with @Transactional.