Announcement Announcement Module
Collapse
No announcement yet.
Possible bug: CONVERSATION_CONTAINER_KEY should be unique per FlowExecutor Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Possible bug: CONVERSATION_CONTAINER_KEY should be unique per FlowExecutor

    I have discovered some unintuitive behavior that I would like to discuss.

    Background: If you configure a FlowExecutor within a single web app using a FlowExecutorFactoryBean, a SessionBindingConversationManager will be instantiated by default as your ConversationManager. This SessionBindingConversationManager will then store a ConversationContainer in the HTTP session under the key "webflow.conversation.container". In addition, you can configure the maxConversations to 1 if you like. This works as expected as long as you only configure only one such FlowExecutor.

    Unintuitive behavior: if you configure multiple, unique FlowExecutors within a single web app using FlowExecutorFactoryBean as described above with maxConversations=1, you will then notice that both FlowExecutors ultimately use the same session key and thus conflict with each other. For example, if you start one flow for FlowExecutor #1 and start another flow which is handled by FlowExecutor #2, the execution of the 2nd flow will destroy the execution of the 1st flow.

    The issue lies in the interpretation of the semantics of maxConversations. As it is currently implemented (i.e., with a single, global session key), the maxConversations takes effect for all configured FlowExecutors within a single web app.

    I believe that this is unintuitive and actually not the desired behavior. If I configure two completely separate FlowExecutors with different flow repositories within a single web app, I expect that the configuration of one of them will not conflict with the configuration of the other.

    What is your opinion of this behavior?

    @Keith & Erwin: is this behavior "as planned"?

    Would it be desirable to generate unique session keys for the ConversationContainer in SessionBindingConversationManager (i.e., unique to the FlowExecutor which uses it)?

    Let me know your thoughts, and if it is considered a "bug" I'd be happy to create a JIRA issue for it.

    Thanks,

    Sam

  • #2
    @Keith & Erwin: is this behavior "as planned"?
    No, 2 independent FlowExecutor definitions should not interfere with each other. Good catch! We'll look into fix this for 1.0.4 and 1.1.

    Erwin

    Comment


    • #3
      http://opensource.atlassian.com/proj...browse/SWF-304

      Fixed!

      Give the next nightly build for 1.0.4 a shot and let me know if that works.

      Erwin

      Comment


      • #4
        Hi Erwin,

        Awesome! That was fast, and you even took care of the JIRA entry.

        Originally posted by klr8 View Post
        Give the next nightly build for 1.0.4 a shot and let me know if that works.
        Sure. I'll try to take a look at that tomorrow.

        cheers and thanks,

        Sam

        Comment


        • #5
          Originally posted by klr8 View Post
          http://opensource.atlassian.com/proj...browse/SWF-304

          Fixed!

          Give the next nightly build for 1.0.4 a shot and let me know if that works.
          I tested it, and...

          Instead of getting a single webflow.conversation.container key in the HTTP session, I now see the following:

          webflow.conversation.container.2B9AC579-9435-DFEE-E0A2-7DA052EA9CEB
          webflow.conversation.container.AAA441FE-6E3D-D580-5323-AF242306E88B

          So it seems to work fine!

          thanks,

          Sam

          p.s. you might consider changing the sessionKey in SessionBindingConversationManager to final.

          Comment


          • #6
            Thanks for testing this!

            Indeed, sessionKey should be final.

            Erwin

            Comment

            Working...
            X