Announcement Announcement Module
No announcement yet.
problem with session clustering Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • problem with session clustering

    Apparently, there seems to be a problem in spring web-flow with clustered sessions. Using terracotta for clustered sessions, load-balancer in round-robin, 2 tomcats, here's how the problem happens (as far as I understand web-flow):

    - request comes in for starting flow (FlowhandlerAdapter.handle)
    - launch flow execution (FlowExecutorImpl.launchExecution)
    - ... other actions in webflow, like entering initial state, execution of state's on-entry, evaluate etc...
    - create conversation and put it in the container (SessionBindingConversationManager.beginConversati on)
    - send redirect for resuming the flow
    - after redirect, request hops to another app server, which does not contain the previously created conversation in its conversationContainer in the session. And hence NoSuchFlowExecutionException.

    Stack trace:
    org.springframework.webflow.execution.repository.N oSuchFlowExecutionException: No flow execution could be found with key 'e1s1' -- perhaps this executing flow has ended or expired? This could happen if your users are relying on browser history (typically via the back button) that references ended flows.
    at org.springframework.webflow.execution.repository.s upport.AbstractFlowExecutionRepository.getConversa tion(
    at org.springframework.webflow.execution.repository.s upport.AbstractFlowExecutionRepository.getLock(Abs
    at org.springframework.webflow.executor.FlowExecutorI mpl.resumeExecution(
    at org.springframework.webflow.mvc.servlet.FlowHandle rAdapter.handle(

    Looking at webflow source, I can see that when resuming flows (FlowExecutorImpl.resumeExecution), it locks and unlocks the conversation, putting back the conversationContainer back in session when unlocking. This takes care of session replication in clustered environments.
    I believe the same thing should also be done just after putting a newly created Conversation in SessionBindingConversationManager.beginConversatio n(). Something like:

    public Conversation beginConversation(ConversationParameters conversationParameters) throws ConversationException {
    return getConversationContainer().createConversation(conv ersationParameters, conversationLockFactory);
    public Conversation beginConversation(ConversationParameters conversationParameters) throws ConversationException {
    Conversation conversation = getConversationContainer().createConversation(conv ersationParameters, conversationLockFactory);
    SharedAttributeMap sessionMap = ExternalContextHolder.getExternalContext().getSess ionMap();
    synchronized (sessionMap.getMutex()) {
    sessionMap.put(sessionKey, conversation);
    return conversation;

  • #2
    created jira

    Created a jira for this --