Details
-
Type: Bug
-
Status: Closed
-
Priority: 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:HideThis 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.
ShowThis 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
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.
-
Hide
- sample-icefaces-jsf-1.2-sun-facelets-portlet-5.0.0.1.war
- 4.41 MB
- Greg Dick
-
- Edit.xhtml 3 kB
- Help.xhtml 2 kB
- JobApplication.xhtml 6 kB
- META-INF/context.xml 0.2 kB
- WEB-INF/classes/.../JobApplication.class 7 kB
- WEB-INF/classes/log4j.properties 0.2 kB
- WEB-INF/classes/log4j.xml 0.8 kB
- WEB-INF/.../messages-override.properties 1 kB
- WEB-INF/faces-config.xml 2 kB
- WEB-INF/geronimo-web.xml 0.5 kB
- WEB-INF/jboss-web.xml 0.3 kB
- WEB-INF/lib/backport-util-concurrent.jar 319 kB
- WEB-INF/lib/icefaces-comps.jar 1.68 MB
- WEB-INF/lib/icefaces-facelets.jar 593 kB
- WEB-INF/lib/icefaces.jar 772 kB
- WEB-INF/lib/jsf-api.jar 316 kB
- WEB-INF/lib/jsf-impl.jar 1.15 MB
- WEB-INF/liferay-display.xml 0.3 kB
- WEB-INF/liferay-plugin-package.properties 0.7 kB
- WEB-INF/liferay-portlet.xml 0.8 kB
- WEB-INF/portlet.xml 2 kB
- WEB-INF/src/.../JobApplication.java 8 kB
- WEB-INF/src/log4j.xml 0.8 kB
- WEB-INF/src/messages-override.properties 1 kB
- WEB-INF/web.xml 4 kB
- portlet-override.css 0.1 kB
Issue Links
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
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.
Assigning to Mircea to review the potential fix.
Create sessions bound servlets lazily.
Re-opened. Reports that this is occurring once again when using current trunk (rev #15814) with Liferay 4.3.x and 4.4.
This problem is highlighted in another case where I've already noted some aspects of the problem.
Closing as a duplicate.
This is happening again in ICEfaces 1.7RC1
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...
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.
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.
Wait for bridge instances to confirm their shutdown before invalidating the session.
There are still some cases when "Session Expired" message comes back right away after a page reload.
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
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.
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."
Shutdown bridge on HTTP 503 errors.
Independently confirmed as fixed in the 1.7.x branch
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.
Adding emptySessionPath="true" attribute to the connector element in the tomcat conf/server.xml file seems to fix this problem