You are viewing a plain text version of this content. The canonical link for it is here.
Posted to pluto-dev@portals.apache.org by Charles Severance <cs...@umich.edu> on 2006/08/27 18:09:22 UTC
Bug in Pluto 1.1 session saving - I think
There is a bug (I think) in session handling in Pluto 1.1. Why
would Pluto 1.1 keep a session across a Tomcat restart!
I think that this has to do with Tomcat's session serialization
across startups and Pluto's blind dependence on Tomcat session for
storing the Pluto session.
../work/Catalina/localhost/sakai-portlets/SESSIONS.ser
If I am crazy - just tell me so.
I have a portlet - with these lines at the beginning:
public void doView(RenderRequest request, RenderResponse response)
throws PortletException, IOException {
PortletSession pSession = request.getPortletSession(true);
String fred = (String) pSession.getAttribute("fred");
System.out.println("Fred = "+fred);
pSession.setAttribute("fred","fred was here");
The "fred" attribute is used no where else in the portlet. Sometimes
the portlet puts non-serializable stuff in session.
[DEBUG] PortletEntityImpl - Loading portlet definition for context: /
sakai-portlets[DEBUG] PortletEntityImpl - Retrieved cross context:
org.apache.catalina.core.ApplicationContextFacade@5e2d6c
[DEBUG] PortletRequestImpl - Retreiving portlet session (create=true)
[DEBUG] PortletRequestImpl - Creating new portlet session...
Fred = null
Ran the portlet in a way that puts a non-serializable thing in session.
Shutdown Tomcat - got the following exception:
WARN: Cannot serialize session attribute javax.portlet.p./sakai-
portlets.SakaiLaunch?site.list for session
77C3CD8BE5687531A4BA57BC87AFCB5C (2006-08-27 11:53:07,973
main_org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/
sakai-portlets])
java.io.NotSerializableException:
org.sakaiproject.portlets.SakaiLaunch$SakaiSite at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1075)
at java.io.ObjectOutputStream.writeArray
(ObjectOutputStream.java:1245) at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1069)
at java.io.ObjectOutputStream.defaultWriteFields
(ObjectOutputStream.java:1369) at
java.io.ObjectOutputStream.defaultWriteObject(ObjectOutputStream.java:
380)
at java.util.Vector.writeObject(Vector.java:1018)
I start Tomcat back up - the serialized file does not exist before I
run my portlet:
ls -l ../work/Catalina/localhost/sakai-portlets/SESSIONS.ser
ls: ../work/Catalina/localhost/sakai-portlets/SESSIONS.ser: No such
file or directory
When my portlet first runs, my session is clean:
[DEBUG] PortletRequestImpl - Retreiving portlet session (create=true)
[DEBUG] PortletRequestImpl - Creating new portlet session...
Fred = null
The serialization file does not exist.
ls -l ../work/Catalina/localhost/sakai-portlets/SESSIONS.ser
ls: ../work/Catalina/localhost/sakai-portlets/SESSIONS.ser: No such
file or directory
Ran ran portlet in such a way that the session data *was* all
serializable.
Shutdown Tomcat - no exceptions and SESSIONS.ser appears :(
ls -l ../work/Catalina/localhost/sakai-portlets/SESSIONS.ser
-rw-r--r-- 1 csev csev 2724 Aug 27 11:43 ../work/Catalina/
localhost/sakai-portlets/SESSIONS.ser
*** Had the fred string in the file
Start Tomcat back up - no exceptions - everything is serializable -
but the session stuff came back (i.e. the value for fred lasted
across server reboots!)
[DEBUG] PortletEntityImpl - Loading portlet definition for context: /
sakai-portlets
[DEBUG] PortletEntityImpl - Retrieved cross context:
org.apache.catalina.core.ApplicationContextFacade@d55e49
[DEBUG] PortletRequestImpl - Retreiving portlet session (create=true)
[DEBUG] PortletRequestImpl - Creating new portlet session...
Fred = fred was here
The workaround is to simply remove the ../work/Catalina/localhost/
sakai-portlets/SESSIONS.ser each time it exists.
And even more clever workaround is to put something horrible and non-
serializable in the session, each time.
This seems like a very bad policy - that portlet session data lives
beyond server restart. This looks like it is Tomcat doing the session
management and Pluto 1.1 is just using the Tomcat Session to store
the data - but we do need inside portlets to know when we are being
run for the first time for a new user to do things like log in and
retrieve web services.
Is there something in my portlet.xml to say "I would like (DUH) a
fresh session when the server restarts" - or is this unspecified
behavior - i it is unspecified - the Pluto 1.1 behavior is wrong.
Login at the pluto debug output - ti seems as though Pluto somehow
*knows* that it is making a session for the first time... WHy not
have Pluto just wipe out anything that Tomcat happens to have laying
around in session related to this Portlet?
This is the version I am using
charles-severances-computer:~/dev/pluto-1.1/pluto-1.1 csev$ svn info
Path: .
URL: http://svn.apache.org/repos/asf/portals/pluto/trunk
Repository Root: http://svn.apache.org/repos/asf
Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
Revision: 434235
Node Kind: directory
Schedule: normal
Last Changed Author: cdoremus
Last Changed Rev: 434172
Last Changed Date: 2006-08-23 16:54:38 -0400 (Wed, 23 Aug 2006)
Properties Last Updated: 2006-05-11 09:16:39 -0400 (Thu, 11 May 2006)
Re: Bug in Pluto 1.1 session saving - I think
Posted by Elliot Metsger <em...@jhu.edu>.
Charles Severance wrote:
> Elliot - That helps a lot. Thanks. I kind of figured it was some
> big obvious RTM thing.
>
> It seems like a curious default - for simple applications you really
> don't want to save across restart - for complex applications where
> folks want dynamic load balancing without requiring stickiness - the
> sessions need to be serialized at the end of each request.
I *think* that by default - e.g. in the absense of a <Manager/> element,
objects that you want to be persisted across restarts should implement
Serializable.
So when Tomcat shuts down with non-serializable session elements, a
java.io.NotSerializableException is thrown when Tomcat is shut down.
> Start Tomcat back up - no exceptions - everything is serializable -
> but the session stuff came back (i.e. the value for fred lasted
> across server reboots!)
If the session hadn't expired, this is, I believe, proper behavior.
> The default configuration kind of does both common Session
> serialization use cases "poorly".
I guess I think that Tomcat is doing what it is supposed to do - if I am
reading your use case example correctly -
Objects that implement Serializable were available across restarts (as
long as the session has not expired, objects should be deserialized into
the current session), and objects that didn't implement Serializable
were not available across restarts (and the exception is thrown).
> But since I can fix it - I am a happy camper.
Excellent :) Hope this helps,
Best,
Elliot
>
> /Chuck
>
> On Aug 27, 2006, at 12:31 PM, Elliot Metsger wrote:
>
>> Charles Severance wrote:
>>
>>> There is a bug (I think) in session handling in Pluto 1.1. Why
>>> would Pluto 1.1 keep a session across a Tomcat restart!
>>>
>>
>> Chuck,
>>
>>
>> Have you tried putting a <Manager pathname=""/> element in your
>> context.xml? The context.xml should be in
>> conf/Catalina/localhost/sakai-portlets.xml. That should disable
>> session persistence across restarts for that context.
>>
>>
>> See also:
>> http://tomcat.apache.org/tomcat-5.5-doc/config/manager.html#Standard%20Implementation,
>> scroll down to the "pathname" attribute and also
>> http://tomcat.apache.org/tomcat-5.5-doc/config/manager.html#Restart%20Persistence
>>
>>
>>
>> HTH,
>>
>> Elliot
>>
>
Re: Bug in Pluto 1.1 session saving - I think
Posted by Charles Severance <cs...@umich.edu>.
Elliot - That helps a lot. Thanks. I kind of figured it was some
big obvious RTM thing.
It seems like a curious default - for simple applications you really
don't want to save across restart - for complex applications where
folks want dynamic load balancing without requiring stickiness - the
sessions need to be serialized at the end of each request.
The default configuration kind of does both common Session
serialization use cases "poorly".
But since I can fix it - I am a happy camper.
/Chuck
On Aug 27, 2006, at 12:31 PM, Elliot Metsger wrote:
> Charles Severance wrote:
>> There is a bug (I think) in session handling in Pluto 1.1. Why
>> would Pluto 1.1 keep a session across a Tomcat restart!
>
> Chuck,
>
> Have you tried putting a <Manager pathname=""/> element in your
> context.xml? The context.xml should be in conf/Catalina/localhost/
> sakai-portlets.xml. That should disable session persistence across
> restarts for that context.
>
> See also: http://tomcat.apache.org/tomcat-5.5-doc/config/
> manager.html#Standard%20Implementation, scroll down to the
> "pathname" attribute and also http://tomcat.apache.org/tomcat-5.5-
> doc/config/manager.html#Restart%20Persistence
>
> HTH,
> Elliot
Re: Bug in Pluto 1.1 session saving - I think
Posted by Elliot Metsger <em...@jhu.edu>.
Charles Severance wrote:
> There is a bug (I think) in session handling in Pluto 1.1. Why would
> Pluto 1.1 keep a session across a Tomcat restart!
Chuck,
Have you tried putting a <Manager pathname=""/> element in your
context.xml? The context.xml should be in
conf/Catalina/localhost/sakai-portlets.xml. That should disable session
persistence across restarts for that context.
See also:
http://tomcat.apache.org/tomcat-5.5-doc/config/manager.html#Standard%20Implementation,
scroll down to the "pathname" attribute and also
http://tomcat.apache.org/tomcat-5.5-doc/config/manager.html#Restart%20Persistence
HTH,
Elliot
>
> I think that this has to do with Tomcat's session serialization across
> startups and Pluto's blind dependence on Tomcat session for storing the
> Pluto session.
>
> ../work/Catalina/localhost/sakai-portlets/SESSIONS.ser
>
> If I am crazy - just tell me so.
>
> I have a portlet - with these lines at the beginning:
>
> public void doView(RenderRequest request, RenderResponse response)
> throws PortletException, IOException {
>
> PortletSession pSession = request.getPortletSession(true);
>
> String fred = (String) pSession.getAttribute("fred");
> System.out.println("Fred = "+fred);
> pSession.setAttribute("fred","fred was here");
>
> The "fred" attribute is used no where else in the portlet. Sometimes
> the portlet puts non-serializable stuff in session.
>
> [DEBUG] PortletEntityImpl - Loading portlet definition for context:
> /sakai-portlets[DEBUG] PortletEntityImpl - Retrieved cross context:
> org.apache.catalina.core.ApplicationContextFacade@5e2d6c
> [DEBUG] PortletRequestImpl - Retreiving portlet session
> (create=true)[DEBUG] PortletRequestImpl - Creating new portlet session...
> Fred = null
>
> Ran the portlet in a way that puts a non-serializable thing in session.
>
> Shutdown Tomcat - got the following exception:
>
> WARN: Cannot serialize session attribute
> javax.portlet.p./sakai-portlets.SakaiLaunch?site.list for session
> 77C3CD8BE5687531A4BA57BC87AFCB5C (2006-08-27 11:53:07,973
> main_org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/sakai-portlets])
>
> java.io.NotSerializableException:
> org.sakaiproject.portlets.SakaiLaunch$SakaiSite at
> java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1075)
> at
> java.io.ObjectOutputStream.writeArray(ObjectOutputStream.java:1245)
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1069)
> at
> java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1369)
> at
> java.io.ObjectOutputStream.defaultWriteObject(ObjectOutputStream.java:380)
> at java.util.Vector.writeObject(Vector.java:1018)
>
> I start Tomcat back up - the serialized file does not exist before I run
> my portlet:
>
> ls -l ../work/Catalina/localhost/sakai-portlets/SESSIONS.ser
> ls: ../work/Catalina/localhost/sakai-portlets/SESSIONS.ser: No such file
> or directory
>
>
> When my portlet first runs, my session is clean:
>
> [DEBUG] PortletRequestImpl - Retreiving portlet session (create=true)
> [DEBUG] PortletRequestImpl - Creating new portlet session...
> Fred = null
>
> The serialization file does not exist.
>
> ls -l ../work/Catalina/localhost/sakai-portlets/SESSIONS.ser
> ls: ../work/Catalina/localhost/sakai-portlets/SESSIONS.ser: No such file
> or directory
>
> Ran ran portlet in such a way that the session data *was* all serializable.
>
> Shutdown Tomcat - no exceptions and SESSIONS.ser appears :(
>
> ls -l ../work/Catalina/localhost/sakai-portlets/SESSIONS.ser
> -rw-r--r-- 1 csev csev 2724 Aug 27 11:43
> ../work/Catalina/localhost/sakai-portlets/SESSIONS.ser
>
> *** Had the fred string in the file
>
> Start Tomcat back up - no exceptions - everything is serializable - but
> the session stuff came back (i.e. the value for fred lasted across
> server reboots!)
>
> [DEBUG] PortletEntityImpl - Loading portlet definition for context:
> /sakai-portlets
> [DEBUG] PortletEntityImpl - Retrieved cross context:
> org.apache.catalina.core.ApplicationContextFacade@d55e49
> [DEBUG] PortletRequestImpl - Retreiving portlet session (create=true)
> [DEBUG] PortletRequestImpl - Creating new portlet session...
> Fred = fred was here
>
> The workaround is to simply remove the
> ../work/Catalina/localhost/sakai-portlets/SESSIONS.ser each time it exists.
>
> And even more clever workaround is to put something horrible and
> non-serializable in the session, each time.
>
> This seems like a very bad policy - that portlet session data lives
> beyond server restart. This looks like it is Tomcat doing the session
> management and Pluto 1.1 is just using the Tomcat Session to store the
> data - but we do need inside portlets to know when we are being run for
> the first time for a new user to do things like log in and retrieve web
> services.
>
> Is there something in my portlet.xml to say "I would like (DUH) a fresh
> session when the server restarts" - or is this unspecified behavior - i
> it is unspecified - the Pluto 1.1 behavior is wrong.
>
> Login at the pluto debug output - ti seems as though Pluto somehow
> *knows* that it is making a session for the first time... WHy not have
> Pluto just wipe out anything that Tomcat happens to have laying around
> in session related to this Portlet?
>
> This is the version I am using
> charles-severances-computer:~/dev/pluto-1.1/pluto-1.1 csev$ svn info
> Path: .
> URL: http://svn.apache.org/repos/asf/portals/pluto/trunk
> Repository Root: http://svn.apache.org/repos/asf
> Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
> Revision: 434235
> Node Kind: directory
> Schedule: normal
> Last Changed Author: cdoremus
> Last Changed Rev: 434172
> Last Changed Date: 2006-08-23 16:54:38 -0400 (Wed, 23 Aug 2006)
> Properties Last Updated: 2006-05-11 09:16:39 -0400 (Thu, 11 May 2006)