MyFaces Orchestra
  1. MyFaces Orchestra
  2. ORCHESTRA-14

ConversationManagerSessionListener leak & IllegalStateException

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.1
    • Fix Version/s: 1.1
    • Component/s: Conversation
    • Labels:
      None
    • Environment:
      tomcat 5

      Description

      ConversationManagerSessionListener has serveral issues:

      1) attributeReplaced sets the old instance of conversationManager in conversationWiperThread instead of the new one
      2) on session expire ConversationManagerSessionListener.attributeRemoved is getting called and session.getId() throws IllegalStateException
      3) ConversationManagerSessionListener.sessionDestroyed will throw a IllegalStateException as well -> method is useless

      Solution:
      1) use a unique id for conversationManager instead of session.getId() as a key in conversationWiperThread
      2) remove HttpSessionListener interface from ConversationManagerSessionListener

        Activity

        Hide
        Thomas Spiegl added a comment -

        resolved

        Show
        Thomas Spiegl added a comment - resolved
        Hide
        Simon Kitching added a comment -

        Thomas, which servlet container are you using?

        I have tested both Jetty and Tomcat 6.0 and neither throws an IllegalStateException when session.getId() is called from the attributeRemoved method while removing attributes from an expired session. The javadocs for the HttpSession class don't say anything either way about whether it is valid to call getId on an invalidated session or not.

        Point (1) indeed looks right. Good catch..

        Show
        Simon Kitching added a comment - Thomas, which servlet container are you using? I have tested both Jetty and Tomcat 6.0 and neither throws an IllegalStateException when session.getId() is called from the attributeRemoved method while removing attributes from an expired session. The javadocs for the HttpSession class don't say anything either way about whether it is valid to call getId on an invalidated session or not. Point (1) indeed looks right. Good catch..
        Hide
        Simon Kitching added a comment -

        Doh..I see you've put "tomcat5" in the environment section of this bug. I'll try testing that.

        Show
        Simon Kitching added a comment - Doh..I see you've put "tomcat5" in the environment section of this bug. I'll try testing that.
        Hide
        Simon Kitching added a comment -

        Hmm..still works for me in Tomcat 5.5.25 as well.

        I enhanced ConversationContextSessionListener.removeAttribute as follows:

        public void attributeRemoved(HttpSessionBindingEvent event)
        {
        log.fatal("Removing attribute " + event.getName());
        try

        { HttpSession session = event.getSession(); session.getId(); log.fatal("IllegalStateException not thrown in attributeRemoved"); }

        catch(IllegalStateException e)

        { log.fatal("IllegalStateException thrown in attributeRemoved"); }

        ....

        And in all the three tested cases (tomcat 5.5.25, tomcat 6.0.15, jetty 6.1.1) I get this:

        10.01.2008 10:32:42 org.apache.myfaces.orchestra.conversation.servlet.ConversationManagerSessionListener attributeRemoved
        SCHWERWIEGEND: Removing attribute jsf_sequence
        10.01.2008 10:32:42 org.apache.myfaces.orchestra.conversation.servlet.ConversationManagerSessionListener attributeRemoved
        SCHWERWIEGEND: IllegalStateException not thrown in attributeRemoved
        10.01.2008 10:32:42 org.apache.myfaces.orchestra.conversation.servlet.ConversationManagerSessionListener attributeRemoved
        SCHWERWIEGEND: Removing attribute org.apache.myfaces.ConversationManager
        10.01.2008 10:32:42 org.apache.myfaces.orchestra.conversation.servlet.ConversationManagerSessionListener attributeRemoved
        SCHWERWIEGEND: IllegalStateException not thrown in attributeRemoved

        Thomas, do you have any idea why you might be seeing problems with session.getId() when I am not?

        Show
        Simon Kitching added a comment - Hmm..still works for me in Tomcat 5.5.25 as well. I enhanced ConversationContextSessionListener.removeAttribute as follows: public void attributeRemoved(HttpSessionBindingEvent event) { log.fatal("Removing attribute " + event.getName()); try { HttpSession session = event.getSession(); session.getId(); log.fatal("IllegalStateException not thrown in attributeRemoved"); } catch(IllegalStateException e) { log.fatal("IllegalStateException thrown in attributeRemoved"); } .... And in all the three tested cases (tomcat 5.5.25, tomcat 6.0.15, jetty 6.1.1) I get this: 10.01.2008 10:32:42 org.apache.myfaces.orchestra.conversation.servlet.ConversationManagerSessionListener attributeRemoved SCHWERWIEGEND: Removing attribute jsf_sequence 10.01.2008 10:32:42 org.apache.myfaces.orchestra.conversation.servlet.ConversationManagerSessionListener attributeRemoved SCHWERWIEGEND: IllegalStateException not thrown in attributeRemoved 10.01.2008 10:32:42 org.apache.myfaces.orchestra.conversation.servlet.ConversationManagerSessionListener attributeRemoved SCHWERWIEGEND: Removing attribute org.apache.myfaces.ConversationManager 10.01.2008 10:32:42 org.apache.myfaces.orchestra.conversation.servlet.ConversationManagerSessionListener attributeRemoved SCHWERWIEGEND: IllegalStateException not thrown in attributeRemoved Thomas, do you have any idea why you might be seeing problems with session.getId() when I am not?
        Hide
        Simon Kitching added a comment -

        Sorry, just to be clear: the attributeRemove calls above are being triggered by a session timeout. I set the session timeout to 3 minutes, visited a few pages then waited. As expected, 3 minutes later there is a sequence of calls to attributeRemoved, one for each attribute in the session.

        Show
        Simon Kitching added a comment - Sorry, just to be clear: the attributeRemove calls above are being triggered by a session timeout. I set the session timeout to 3 minutes, visited a few pages then waited. As expected, 3 minutes later there is a sequence of calls to attributeRemoved, one for each attribute in the session.
        Hide
        Thomas Spiegl added a comment -

        patch committed

        Show
        Thomas Spiegl added a comment - patch committed

          People

          • Assignee:
            Thomas Spiegl
            Reporter:
            Thomas Spiegl
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development