It would be helpful if you tried it in a different container and report your findings, and/or create a JIRA issue with a small sameple application that can be used to reproduce the error.
Are you by any chance calling "clear()" on the session map? That would invalidate the session. Nils-H On Wed, Apr 15, 2009 at 3:40 PM, Kofford, C Todd <tkoff...@ku.edu> wrote: > I'm using session scope (implements SessionAware). > > No, I haven't deployed to a different portlet container. > > Todd Kofford > tkoff...@ku.edu > University of Kansas - IT > > > -----Original Message----- > From: Nils-Helge Garli Hegvik [mailto:nil...@gmail.com] > Sent: Wednesday, April 15, 2009 4:05 AM > To: Struts Users Mailing List > Subject: Re: Struts 2 Portlet - Intermittent Session Problems > > As long as you're using the portlet session, and not the > APPLICATION_SCOPE session, the sessions shouldn't interfere. Which > container are you running in? Have you tried deploying to a different > portlet container? > > Nils-H > > On Tue, Apr 14, 2009 at 8:01 PM, Kofford, C Todd <tkoff...@ku.edu> wrote: >> Hi Nils, >> >> Well this issue cannot be reproduced on a consistent basis. I can do the >> same operation 4 times and 3 of the 4 times it works properly, but one time >> it doesn't and the session disappears. It's very random. >> >> One thing that might be noteworthy is that I have 2 portlets defined for the >> same web application. To clarify, I have one parking web application that >> handles both citations and permit purchases. Citations and Permits are >> defined as two individual portlets in the our portal, and both point to the >> same parking webapp. >> >> I don't know if this is an issue or not. As random as this error is, I'm >> wondering if the some jars are getting loaded up twice by tomcat and >> randomly switching between two copies (of the same jar) as the requests are >> processed. >> >> Also to note is that this problem does not happen when the application(s) >> are run outside the portal (i.e. as standalone webapps). >> >> Todd Kofford >> tkoff...@ku.edu >> University of Kansas - IT >> >> >> -----Original Message----- >> From: Nils-Helge Garli Hegvik [mailto:nil...@gmail.com] >> Sent: Friday, April 10, 2009 5:20 PM >> To: Struts Users Mailing List >> Subject: Re: Struts 2 Portlet - Intermittent Session Problems >> >> Hi! >> >> The PortletStateInterceptor does nothing special with the Session. It >> certainly does not invalidate it or remove stuff that's already there. >> The debug statement that you see is an indication that the portlet has >> been executed in the event phase, and the result has been properly >> configured with a redirectAction result. As a matter of fact, that log >> statement indicates that the interceptor is bypassing it's normal >> executing and does essentially nothing. >> >> Is this something you can reproduce consistently? In that case, do you >> have a sample that you could attach to a JIRA issue? Without more >> information, it's impossible to say what the problem could be (besides >> a regular session timeout or something...) >> >> Nils-H >> >> On Fri, Apr 10, 2009 at 10:13 PM, Kofford, C Todd <tkoff...@ku.edu> wrote: >>> I have a struts 2 (version 2.1.6) portlet that I keep seeing >>> intermittent problems with the session being wiped out. Each time this >>> happens I see the following messages in the log: >>> >>> DEBUG [Thread-57] interceptor.PortletStateInterceptor.[] Apr/10 14:26:57 >>> - Won't restore stack from event phase since it's a proper PRG request >>> ... >>> DEBUG [Thread-57] PermitBaseAction.[] Apr/10 14:26:57 - session = {} >>> >>> I'm not sure what is going on here. In the event phase just prior to >>> this render phase, my session is populated but then the "...proper RPG >>> request" happens and my session is gone. I'm assuming that the portlet >>> plugin gets into an invalid/mixed up state. But what would cause this? >>> >>> Any help would be appreciated. >>> >>> Todd Kofford >>> tkoff...@ku.edu >>> University of Kansas - IT >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: user-unsubscr...@struts.apache.org >>> For additional commands, e-mail: user-h...@struts.apache.org >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: user-unsubscr...@struts.apache.org >> For additional commands, e-mail: user-h...@struts.apache.org >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: user-unsubscr...@struts.apache.org >> For additional commands, e-mail: user-h...@struts.apache.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: user-unsubscr...@struts.apache.org > For additional commands, e-mail: user-h...@struts.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: user-unsubscr...@struts.apache.org > For additional commands, e-mail: user-h...@struts.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
