ICEfaces
  1. ICEfaces
  2. ICE-2152

User Session Expired when re-hot-deploying Liferay portlets

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.6
    • Fix Version/s: 1.7.1
    • Component/s: None
    • Labels:
      None
    • Environment:
      Liferay 4.3.2 / Tomcat 6.0.13
    • Workaround Exists:
      Yes
    • Workaround Description:
      Hide
      This is *kind of* a workaround, but only in the case of development (circumstance#1 listed above). If you click on the "Home" tab to go to your Liferay portal home page, then re-hot-deploy, and then visit the page with the ICEfaces portlet again, it seems to work OK.

      But this is by no means a workaround in circumstance#2, because you can't rely on employees/customers to know that they need to do this.
      Show
      This is *kind of* a workaround, but only in the case of development (circumstance#1 listed above). If you click on the "Home" tab to go to your Liferay portal home page, then re-hot-deploy, and then visit the page with the ICEfaces portlet again, it seems to work OK. But this is by no means a workaround in circumstance#2, because you can't rely on employees/customers to know that they need to do this.

      Description

      This is very easy to reproduce:

      1. Download Liferay 4.3.2 / Tomcat 6.0.13 bundle and extract

      2. Download the sample-icefaces-sun-portlet from the Liferay website

      3. COPY (don't move) the sample-icefaces-sun-portlet in your $HOME/liferay/deploy folder (hot deploy folder)

      4. Verify in the Tomcat console that the portlet plugin extracts and registers itself

      5. Startup IE7, and add the portlet to a page (and keep viewing the page)

      6. Repeat step #3 and #4

      7. Click Reload button

      At this point you should get the "User Session Expired" error message, and the only way to fix it is to restart Tomcat.

      Now this is a problem under two circumstances:

      1. When developers are creating ICEfaces portlets, they often want to incrementally test their changes. The way to do this in Liferay is to keep re-hot-deploying the portlet, but the "User Session Expired" error message is not exactly thruthful, in that the user is still able to visit other portal pages and continue to use Liferay.

      2. When Portal administrators download new versions of Liferay portlet plugins, and want to deploy them to their employees/customers in their intranet. But Portal admins aren't always in a position where they can restart Tomcat, because it might be in the middle of a work day, or a mission-critical system.

        Issue Links

          Activity

          Hide
          Mike Lawrence added a comment -

          Adding emptySessionPath="true" attribute to the connector element in the tomcat conf/server.xml file seems to fix this problem

          Show
          Mike Lawrence added a comment - Adding emptySessionPath="true" attribute to the connector element in the tomcat conf/server.xml file seems to fix this problem
          Hide
          Deryk Sinotte added a comment -

          While Mike's suggested fix makes sense for Tomcat-based deployments, it likely won't apply to other portal implementations. In addition, it looks like it may not be a good solution for some environments even if they are based on Tomcat.

          The problem seems to be in our SessionDispatcher. We have a listener that listens for sessionCreated events and keeps a record of the session IDs. Incoming requests are dispatched appropriately based on matching the sessionID. This works well in a plain web app because when you hot deploy, everything gets reset. However, in a portlet environment, when you hot deploy a single portlet, the only thing that gets reset is the SessionDispatcher's listener for that portlet. The users session (which potentially spans many portlets) is still valid but the listener list for the newly re-deployed portlet will be empty and no new sessionCreated event will be fired. So incoming requests to that portlet will incorrectly be turned away because there is no record of the sessionID in the SessionDispatcher's collection.

          Show
          Deryk Sinotte added a comment - While Mike's suggested fix makes sense for Tomcat-based deployments, it likely won't apply to other portal implementations. In addition, it looks like it may not be a good solution for some environments even if they are based on Tomcat. The problem seems to be in our SessionDispatcher. We have a listener that listens for sessionCreated events and keeps a record of the session IDs. Incoming requests are dispatched appropriately based on matching the sessionID. This works well in a plain web app because when you hot deploy, everything gets reset. However, in a portlet environment, when you hot deploy a single portlet, the only thing that gets reset is the SessionDispatcher's listener for that portlet. The users session (which potentially spans many portlets) is still valid but the listener list for the newly re-deployed portlet will be empty and no new sessionCreated event will be fired. So incoming requests to that portlet will incorrectly be turned away because there is no record of the sessionID in the SessionDispatcher's collection.
          Hide
          Deryk Sinotte added a comment -

          Assigning to Mircea to review the potential fix.

          Show
          Deryk Sinotte added a comment - Assigning to Mircea to review the potential fix.
          Hide
          Mircea Toma added a comment -

          Create sessions bound servlets lazily.

          Show
          Mircea Toma added a comment - Create sessions bound servlets lazily.
          Hide
          Ken Fyten added a comment -

          Re-opened. Reports that this is occurring once again when using current trunk (rev #15814) with Liferay 4.3.x and 4.4.

          Show
          Ken Fyten added a comment - Re-opened. Reports that this is occurring once again when using current trunk (rev #15814) with Liferay 4.3.x and 4.4.
          Hide
          Deryk Sinotte added a comment -

          This problem is highlighted in another case where I've already noted some aspects of the problem.

          Show
          Deryk Sinotte added a comment - This problem is highlighted in another case where I've already noted some aspects of the problem.
          Hide
          Deryk Sinotte added a comment -

          Closing as a duplicate.

          Show
          Deryk Sinotte added a comment - Closing as a duplicate.
          Hide
          Neil Griffin added a comment -

          This is happening again in ICEfaces 1.7RC1

          Show
          Neil Griffin added a comment - This is happening again in ICEfaces 1.7RC1
          Hide
          Maxi Ng added a comment -

          This is happening to me.
          Icefaces 1.7RC1 with liferay-portal-jboss-tomcat-4.2-4.4.2.
          I am a jboss user so the tomcat fix won't work.
          Restart the server won't fix this problem either.
          There is no point to use portlet if I can only put one of them in one page...

          Show
          Maxi Ng added a comment - This is happening to me. Icefaces 1.7RC1 with liferay-portal-jboss-tomcat-4.2-4.4.2. I am a jboss user so the tomcat fix won't work. Restart the server won't fix this problem either. There is no point to use portlet if I can only put one of them in one page...
          Hide
          Neil Griffin added a comment -

          Maxi – after the folks at ICEsoft have fixed this error, you should be able to place more than one ICEfaces portlet on a Liferay portal page. According to the new ICEfaces Developer's Guide, each portlet must use the same version of ICEfaces.

          Show
          Neil Griffin added a comment - Maxi – after the folks at ICEsoft have fixed this error, you should be able to place more than one ICEfaces portlet on a Liferay portal page. According to the new ICEfaces Developer's Guide, each portlet must use the same version of ICEfaces.
          Hide
          Aaron Lucas added a comment -

          I am having a similar problem (I have set emptySessionPath=true) and the user session expired popup stops, but it looks as if session attributes that are part of Liferay are also being reset, could this be from the sessiondispatcher as well??

          In liferay you can chose to share session attributes from the portal to the portlet by adding the attribute names to the portal-ext.properties file, namely the shared.session.attributes property.

          I am able to see any attribute that I sit in this file fine with a regular jsf 1.2 portlet but the moment I use the ICEFACES version of the portlet all the values disappear

          I am using IcEfaces 1.7.0 RC1 Tomcat 6 and Liferay 4.4.2 .

          I have posted in the portlet portal forum here at icefaces (http://www.icefaces.org/JForum/posts/list/7735.page) and on liferay's development forum. I have tried everything that I know to fix the problem but it seems to be something inherent with ICEfaces.

          Show
          Aaron Lucas added a comment - I am having a similar problem (I have set emptySessionPath=true) and the user session expired popup stops, but it looks as if session attributes that are part of Liferay are also being reset, could this be from the sessiondispatcher as well?? In liferay you can chose to share session attributes from the portal to the portlet by adding the attribute names to the portal-ext.properties file, namely the shared.session.attributes property. I am able to see any attribute that I sit in this file fine with a regular jsf 1.2 portlet but the moment I use the ICEFACES version of the portlet all the values disappear I am using IcEfaces 1.7.0 RC1 Tomcat 6 and Liferay 4.4.2 . I have posted in the portlet portal forum here at icefaces ( http://www.icefaces.org/JForum/posts/list/7735.page ) and on liferay's development forum. I have tried everything that I know to fix the problem but it seems to be something inherent with ICEfaces.
          Hide
          Mircea Toma added a comment -

          Wait for bridge instances to confirm their shutdown before invalidating the session.

          Show
          Mircea Toma added a comment - Wait for bridge instances to confirm their shutdown before invalidating the session.
          Hide
          Mircea Toma added a comment -

          There are still some cases when "Session Expired" message comes back right away after a page reload.

          Show
          Mircea Toma added a comment - There are still some cases when "Session Expired" message comes back right away after a page reload.
          Hide
          David Wainwright added a comment -

          I'm having this problem with ICEfaces1.7, Liferay 5.0.1, SunRI1.2, JBoss4.2.2 & Tomcat6. One portlet on the page is ok, two or more portlets means trouble. Restarting the server doesn't alway help. I've voted for this issue as it pretty critical for us.

          Dwainwr

          Show
          David Wainwright added a comment - I'm having this problem with ICEfaces1.7, Liferay 5.0.1, SunRI1.2, JBoss4.2.2 & Tomcat6. One portlet on the page is ok, two or more portlets means trouble. Restarting the server doesn't alway help. I've voted for this issue as it pretty critical for us. Dwainwr
          Hide
          Mircea Toma added a comment -

          After taking a closer look, testing on Liferay 4.4.2 and 5.0.1, and hot-re-deploying component-showcase portlets after and before session expired I could not to reproduce at all.

          Show
          Mircea Toma added a comment - After taking a closer look, testing on Liferay 4.4.2 and 5.0.1, and hot-re-deploying component-showcase portlets after and before session expired I could not to reproduce at all.
          Hide
          Mircea Toma added a comment -

          Looks like this issue still manifests itself when re-hot-deploying with Liferay SDK. Neil has described in an email how this issue can be reproduced:

          "Once you have downloaded the Liferay+AppServer bundle and the Plugins SDK, you need to "point" your plugins SDK to the Liferay+AppServer bundle by making a build.mircea.properties (using the appropriate username from your OS) file and placing it in the root folder of the Plugins SDK. See attached build.ngriffin.properties for an example.

          The next step is to extract the attached sample-icefaces-jsf-1.1-sun-facelets-portlet.zip archive into the "portlets" folder of the Plugins SDK. Once extracted, type "ant deploy" from within the plugins-sdk/portlets/sample-icefaces-jsf-1.1-sun-facelets folder. That should compile the source and copy the .war to your hot deploy folder.

          Now, ICE-2152 manifests itself when portlets are re-hot-deployed. This is a typical thing for a developer to do, as he is developing portlet functionality. So after you have deployed the portlet the first time and have it working on a Liferay portal page, keep your browser pointing to the same portal page and then re-execute the "ant deploy" command. After the Tomcat log indicates that Liferay has successfully re-hot-deployed the portlet, click the Refresh/Reload button in your browser, and you'll see the "User Session Expired" message."

          Show
          Mircea Toma added a comment - Looks like this issue still manifests itself when re-hot-deploying with Liferay SDK. Neil has described in an email how this issue can be reproduced: "Once you have downloaded the Liferay+AppServer bundle and the Plugins SDK, you need to "point" your plugins SDK to the Liferay+AppServer bundle by making a build.mircea.properties (using the appropriate username from your OS) file and placing it in the root folder of the Plugins SDK. See attached build.ngriffin.properties for an example. The next step is to extract the attached sample-icefaces-jsf-1.1-sun-facelets-portlet.zip archive into the "portlets" folder of the Plugins SDK. Once extracted, type "ant deploy" from within the plugins-sdk/portlets/sample-icefaces-jsf-1.1-sun-facelets folder. That should compile the source and copy the .war to your hot deploy folder. Now, ICE-2152 manifests itself when portlets are re-hot-deployed. This is a typical thing for a developer to do, as he is developing portlet functionality. So after you have deployed the portlet the first time and have it working on a Liferay portal page, keep your browser pointing to the same portal page and then re-execute the "ant deploy" command. After the Tomcat log indicates that Liferay has successfully re-hot-deployed the portlet, click the Refresh/Reload button in your browser, and you'll see the "User Session Expired" message."
          Hide
          Mircea Toma added a comment -

          Shutdown bridge on HTTP 503 errors.

          Show
          Mircea Toma added a comment - Shutdown bridge on HTTP 503 errors.
          Hide
          Neil Griffin added a comment -

          Independently confirmed as fixed in the 1.7.x branch

          Show
          Neil Griffin added a comment - Independently confirmed as fixed in the 1.7.x branch
          Hide
          Greg Dick added a comment -

          I think this is a version of the sample that works ok.

          Show
          Greg Dick added a comment - I think this is a version of the sample that works ok.
          Hide
          Aaron Lucas added a comment -

          Happening with Liferay 4.4.2 and Icefaces 1.7.1, dropping portlet.war into liferay deploy folder, go to liferay add portlet, immediately see user session expired.

          Show
          Aaron Lucas added a comment - Happening with Liferay 4.4.2 and Icefaces 1.7.1, dropping portlet.war into liferay deploy folder, go to liferay add portlet, immediately see user session expired.

            People

            • Assignee:
              Unassigned
              Reporter:
              Neil Griffin
            • Votes:
              4 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: