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

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

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

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.