4 Replies Latest reply on Feb 21, 2014 4:42 AM by Markus Unger

    Session invalid problem after switch from Wildfly 8.0.0 RC1 to Final

    Markus Unger Newbie

      Hello,

       

      i have the following problem:

      At the moment our application is running on jboss 6 and websphere. Our plan was to migrate to wildfly which in the begining works really good.

      But with the change from RC1 to Final we got a strange effect: No Login is possible in our application because of an "invalid session".

      Direct with the first request the framework we are using says:

      "The session you worked in was not available anymore on server side."

      and throws an exception.

      Furthermore if you dont click on our "login" button a heartbeat will do the same. After 30 seconds you also get an "The session you worked in was not available anymore on server side." error.

       

      The exception which is thrown by our used framework is:

       

      org.eclnt.client.comm.http.SessionTimeoutException

      at org.eclnt.client.comm.http.DataTransfer.transferXML(DataTransfer.java:908)

      at org.eclnt.client.comm.http.DataTransfer.communicateToServerSynchronous(DataTransfer.java:257)

      at org.eclnt.client.page.Page.transferDataRun(Page.java:1172)

      at org.eclnt.client.page.Page$DataTransferRunner.run(Page.java:150)

      at org.eclnt.client.page.Page.callServerRun(Page.java:1142)

      at org.eclnt.client.page.Page$CallServerRunner.run(Page.java:110)

      at java.awt.event.InvocationEvent.dispatch(Unknown Source)

      at java.awt.EventQueue.dispatchEventImpl(Unknown Source)

      at java.awt.EventQueue.access$200(Unknown Source)

      at java.awt.EventQueue$3.run(Unknown Source)

      at java.awt.EventQueue$3.run(Unknown Source)

      at java.security.AccessController.doPrivileged(Native Method)

      at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)

      at java.awt.EventQueue.dispatchEvent(Unknown Source)

      at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)

      at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)

      at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)

      at java.awt.EventDispatchThread.pumpEvents(Unknown Source)

      at java.awt.EventDispatchThread.pumpEvents(Unknown Source)

      at java.awt.EventDispatchThread.run(Unknown Source)

       

      Unfortunately in the Wildfly log nothing is logged which could help me why the session should not exist anymore.

      Our Frameworks on the other side logs different Session IDs with Wildfly Final. In the RC1 all Session IDs are the same.

      I tried it with three different browsers (just to be sure): Firefox, IE and Google Chrome. No difference.

      The system where i run Wildfly is a Windows 7 Pro with Java 7.0.45.

       

      So my question would be, where is the difference between RC1 and Final which would affect the session handling in this way?

      Has anybody an idea how to solve this?

       

      Thank you for every hint.

         Markus

        • 1. Re: Session invalid problem after switch from Wildfly 8.0.0 RC1 to Final
          Tomaz Cerar Master

          Hi,

           

          how does your undertow subsystem configuration look like?

          Also what is session configuration in your web.xml

          • 2. Re: Session invalid problem after switch from Wildfly 8.0.0 RC1 to Final
            Markus Unger Newbie

            Hello Tomaz,

             

            this is our undertow config. It is not changed (direct from the Wildfly-Final zip file).

             

              <subsystem xmlns="urn:jboss:domain:undertow:1.0">

                        <buffer-caches>

                            <buffer-cache name="default" buffer-size="1024" buffers-per-region="1024" max-regions="10"/>

                        </buffer-caches>

                        <server name="default-server">

                            <http-listener name="default" socket-binding="http"/>

                            <host name="default-host" alias="localhost">

                                <location name="/" handler="welcome-content"/>

                                <filter-ref name="server-header"/>

                                <filter-ref name="x-powered-by-header"/>

                            </host>

                        </server>

                        <servlet-container name="default" default-buffer-cache="default" stack-trace-on-error="local-only">

                            <jsp-config/>

                        </servlet-container>

                        <handlers>

                            <file name="welcome-content" path="${jboss.home.dir}/welcome-content" directory-listing="true"/>

                        </handlers>

                        <filters>

                            <response-header name="server-header" header-name="Server" header-value="Wildfly 8"/>

                            <response-header name="x-powered-by-header" header-name="X-Powered-By" header-value="Undertow 1"/>

                        </filters>

                    </subsystem>

             

            in our web.xml the session config looks like this:

            <session-config>

                <session-timeout>30</session-timeout>

              </session-config>

             

            nothing special i would think...

             

            Greetings

              Markus

            • 3. Re: Session invalid problem after switch from Wildfly 8.0.0 RC1 to Final
              Markus Unger Newbie

              Hello,

               

              after doing some further research i found the following:

              We use a Framework (called CaptainCasa) which is splitted in an server and a client Part (http://www.captaincasa.com/). The client is just a rendering and event processing engine, the other part is done on server side.

              Now i examined the logfile of both parts and found out that the jsessionid is not send to the client in the Final Version of Wildfly. RC1 is doing that.

               

              Here is the part of the CaptainCasa Client Log with Wildfly Final: No jsessionid.

              2014:02:18 10:48:59:611 | 33 | INFO | Server = http://127.0.0.1:8080 .......... org.eclnt.client.page.PageBrowser>loadHeaderURL
              2014:02:18 10:48:59:611 | 33 | INFO | Address = /anafee/faces/jsps/start.jsp .......... org.eclnt.client.page.PageBrowser>loadHeaderURL
              2014:02:18 10:48:59:611 | 33 | INFO | Jsessionid = null .......... org.eclnt.client.page.PageBrowser>loadHeaderURL
              2014:02:18 10:48:59:611 | 33 | INFO | Address = /anafee/faces/jsps/start.jsp .......... org.eclnt.client.page.PageBrowser>loadHeaderURL
              2014:02:18 10:48:59:611 | 33 | INFO | m_fullRootNS = /anafee .......... org.eclnt.client.page.Page><init>
              2014:02:18 10:48:59:611 | 33 | INFO | m_imageRootNS = /anafee/jsps .......... org.eclnt.client.page.Page><init>
              2014:02:18 10:48:59:611 | 33 | INFO | transfer of XML started, assembling request .......... org.eclnt.client.comm.http.DataTransfer>transferXML
              2014:02:18 10:48:59:612 | 33 | INFO | The requestid is: 6094164_13 .......... org.eclnt.client.comm.http.DataTransfer>transferXML

               

               

              With Wildfly RC1 a jsessionid is sent and can be used.

              2014:02:18 11:04:00:387 | 34 | INFO | Server = http://127.0.0.1:8080 .......... org.eclnt.client.page.PageBrowser>loadHeaderURL
              2014:02:18 11:04:00:387 | 34 | INFO | Address = /anafee/faces/jsps/start.jsp .......... org.eclnt.client.page.PageBrowser>loadHeaderURL
              2014:02:18 11:04:00:387 | 34 | INFO | Jsessionid = WDth6tCpP0qI7sPI9qTWyWZs .......... org.eclnt.client.page.PageBrowser>loadHeaderURL
              2014:02:18 11:04:00:387 | 34 | INFO | Address = /anafee/faces/jsps/start.jsp;jsessionid=WDth6tCpP0qI7sPI9qTWyWZs?cc_clearDump=true .......... org.eclnt.client.page.PageBrowser>loadHeaderURL
              2014:02:18 11:04:00:387 | 34 | INFO | m_fullRootNS = /anafee .......... org.eclnt.client.page.Page><init>
              2014:02:18 11:04:00:387 | 34 | INFO | m_imageRootNS = /anafee/jsps .......... org.eclnt.client.page.Page><init>
              2014:02:18 11:04:00:387 | 34 | INFO | transfer of XML started, assembling request .......... org.eclnt.client.comm.http.DataTransfer>transferXML
              2014:02:18 11:04:00:388 | 34 | INFO | The requestid is: 4145647_13 .......... org.eclnt.client.comm.http.DataTransfer>transferXML

               

              but now comes the interesting part:

              The CaptainCasa Server Log says there is a jsessionid. In Wildfly RC1 exactly this session id can be found in the Client-Log of CaptainCasa. In the Wildfly Final its null.

              2014:02:18 10:48:59:613 | 255| INFO | >>>>>>>>>> request to be processed -------------------------------------------
              2014:02:18 10:48:59:615 | 255| INFO | Session created - creating session instance of HttpSessionListenerDelegator, sessionId: wNItn3TdIaSAO5YTN5XtyGw1
              2014:02:18 10:48:59:615 | 255| INFO | Initializing session info
              2014:02:18 10:48:59:615 | 255| INFO | Reading /eclntjsfserver/config/sessiondefaults.xml

               

              My question now would be: what part is responsible for not appending the jsessionid and why does it work in RC1 and not in Final?

              I am not sure, but is this function related with session URL rewriting?

               

              Greetings

                Markus

              • 4. Re: Session invalid problem after switch from Wildfly 8.0.0 RC1 to Final
                Markus Unger Newbie

                Hello

                i found a solution.

                Our framework needs the jsessionid in the URL, not as cookie.

                It seems that Wildfly RC1 sends the jsessionid with the URL and Wildfly Final sends it with cookies as default.

                 

                So here is the solution to switch from Cookie to URL rewriting:

                You have to modify your web.xml and add the following line to the <session-config> block:

                <tracking-mode>URL</tracking-mode>

                 

                Our session-config block in the web.xml now looks like this:

                <session-config>

                    <session-timeout>30</session-timeout>

                    <tracking-mode>URL</tracking-mode>

                </session-config>

                 

                and then everything is working again.

                 

                Greetings

                  Markus