3 Replies Latest reply on Mar 5, 2014 11:55 AM by Radoslav Husar

    WildFly session id not change when timeout?

    Minglei Lee Newbie

      I tried to set the session timeout in web.xml (or using session.setMaxInactiveInterval). The destory event can be received in my HttpSessionListener's sessionDestroyed method. But after that, I refreshed the page, the session id is still same to the old one, although all the old session's attributes are all cleared.


      I don't think that the new session should have the same id to the old one. I tried JBoss AS7 and Tomcat 7, both generate a new session id.


      Is it a bug in WildFly?


      Thanks

        • 1. Re: WildFly session id not change when timeout?
          Radoslav Husar Master

          I noticed this a while ago too, looks like a bug to me too, the ID should not be recycled.

           

          [rhusar@x220 script]$ curl http://localhost:8080/clusterbench/session --no-keepalive -b ck.txt -c ck.txt
          0
          [rhusar@x220 script]$ curl http://localhost:8080/clusterbench/session --no-keepalive -b ck.txt -c ck.txt
          1
          [rhusar@x220 script]$ curl http://localhost:8080/clusterbench/session --no-keepalive -b ck.txt -c ck.txt
          2
          [rhusar@x220 script]$ curl http://localhost:8080/clusterbench/session --no-keepalive -b ck.txt -c ck.txt
          3
          [rhusar@x220 script]$ curl http://localhost:8080/clusterbench/session --no-keepalive -b ck.txt -c ck.txt
          4
          [rhusar@x220 script]$ curl http://localhost:8080/clusterbench/session --no-keepalive -b ck.txt -c ck.txt
          5
          [rhusar@x220 script]$ cat ck.txt
          # Netscape HTTP Cookie File
          # http://curl.haxx.se/docs/http-cookies.html
          # This file was generated by libcurl! Edit at your own risk.
          
          
          localhost FALSE /clusterbench FALSE 0 JSESSIONID byQZoVgzKHYrH2qSD-sH25A_.x
          [rhusar@x220 script]$ sleep 60; curl http://localhost:8080/clusterbench/session --no-keepalive -b ck.txt -c ck.txt
          0
          [rhusar@x220 script]$ cat ck.txt
          # Netscape HTTP Cookie File
          # http://curl.haxx.se/docs/http-cookies.html
          # This file was generated by libcurl! Edit at your own risk.
          
          
          localhost FALSE /clusterbench FALSE 0 JSESSIONID byQZoVgzKHYrH2qSD-sH25A_.x
          [rhusar@x220 script]$ 5~^Ceep 60; curl http://localhost:8080/clusterbench/session --no-keepalive -b ck.txt -c ck.txt
          [rhusar@x220 script]$ curl http://localhost:8080/clusterbench/session --no-keepalive -b ck.txt -c ck.txt
          1[rhusar@x220 script]$ at ck.txt
          # Netscape HTTP Cookie File
          # http://curl.haxx.se/docs/http-cookies.html
          # This file was generated by libcurl! Edit at your own risk.
          
          
          localhost FALSE /clusterbench FALSE 0 JSESSIONID byQZoVgzKHYrH2qSD-sH25A_.x
          
          • 2. Re: WildFly session id not change when timeout?
            Paul Ferraro Master

            I realize that this behavior is different than it was in AS7, but I'm not sure I'd call it a bug.  I don't see anything in the servlet spec that states that the session identifier of the new session cannot be the same as the previously invalidated one, so long as the attributes get cleared and its meta data reset, i.e. HttpSession.isNew() should return true.

            Ideally though, we ought to use a new session identifier, otherwise this might cause issues for distributable web applications that use ASYNC replication.

            Is there a jira for this?

            • 3. Re: WildFly session id not change when timeout?
              Radoslav Husar Master

              Is there a jira for this?

              WildFly session id not change when timeout?

              I didn't create one yet.

               

              i.e. HttpSession.isNew() should return true.

              It does -- so all that is fine.

               

              Ideally though, we ought to use a new session identifier, otherwise this might cause issues for distributable web applications that use ASYNC replication.

              +1