-
Bug
-
Resolution: Won't Fix
-
Medium (View bug fix roadmap)
-
None
-
2.1 Pro
-
2.01
-
This is actually a Open Symphony error - it looks as though the log4J logger in the User object is not marked as transient...
I have a number of these errors in the logs.
2003-06-12 20:57:14 StandardContext[]: Reloading this Context is completed
2003-06-12 23:32:53 StandardManager[] Cannot serialize session attribute os_security_defaultauthenticator_user for session B7F30118137340E1701B9B2FB6D1C17D
java.io.NotSerializableException: org.apache.log4j.Logger
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1054)
at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1330)
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1302)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1245)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:278)
at java.util.ArrayList.writeObject(ArrayList.java:530)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:795)
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1294)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1245)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052)
at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1330)
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1302)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1245)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052)
at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1330)
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1302)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1245)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052)
at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1330)
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1302)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1245)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:278)
at org.apache.catalina.session.StandardSession.writeObject(StandardSession.java:1427)
at org.apache.catalina.session.StandardSession.writeObjectData(StandardSession.java:869)
at org.apache.catalina.session.StandardManager.unload(StandardManager.java:507)
at org.apache.catalina.session.StandardManager.stop(StandardManager.java:662)
at org.apache.catalina.core.StandardContext.stop(StandardContext.java:3591)
at org.apache.catalina.core.ContainerBase.removeChild(ContainerBase.java:1036)
at org.apache.catalina.core.StandardHostDeployer.remove(StandardHostDeployer.java:420)
at org.apache.catalina.core.StandardHost.remove(StandardHost.java:852)
at org.apache.catalina.startup.HostConfig.undeployApps(HostConfig.java:919)
at org.apache.catalina.startup.HostConfig.stop(HostConfig.java:899)
at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:370)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:166)
at org.apache.catalina.core.ContainerBase.stop(ContainerBase.java:1221)
at org.apache.catalina.core.ContainerBase.stop(ContainerBase.java:1233)
at org.apache.catalina.core.StandardService.stop(StandardService.java:554)
at org.apache.catalina.core.StandardServer.stop(StandardServer.java:2224)
at org.apache.catalina.startup.Catalina$CatalinaShutdownHook.run(Catalina.java:622)
– Nick Minutello
- is related to
-
-
- Closed
-
-
JRASERVER-5730
NotSerializableException in 3.0.3 under JBoss 4.0
-
- Closed
-
- relates to
-
-
- Closed
-
-
-
- Closed
-
- was split into
-
-
- Closed
-
[JRASERVER-1909] java.io.NotSerializableException: org.apache.log4j.Logger
We're getting this message intermittently too: IOException while loading persisted sessions: java.io.WriteAbortedException: writing aborted; java.io.NotSerializableException: org.apache.log4j.Logger
java.io.WriteAbortedException: writing aborted; java.io.NotSerializableException: org.apache.log4j.Logger
Running Tomcat 4.1.29.
Stefan Hannuschke
added a comment - I'm running JIRA on Tomcat 5.5.9 and get the following on startup:
Mar 18, 2006 2:24:02 PM org.apache.catalina.session.PersistentManagerBase start
SEVERE: No Store configured, persistence disabled
I believe this is due to the workaround
<Manager className="org.apache.catalina.session.PersistentManager" saveOnRestart="false"/>
Reading up the Tocat docs, they say "If you are using the Persistent Manager Implementation as described above, you MUST nest a <Store> element inside,...".
Adding a simple filebased store, i.e.
<Manager className="org.apache.catalina.session.PersistentManager" saveOnRestart="false">
<Store className="org.apache.catalina.session.FileStore"/>
</Manager>
solved that as well.
Adding the directory attribute and putting this on a clustered FS might help in clustering as well.
Stefan Hannuschke
added a comment - I'm running JIRA on Tomcat 5.5.9 and get the following on startup:
Mar 18, 2006 2:24:02 PM org.apache.catalina.session.PersistentManagerBase start
SEVERE: No Store configured, persistence disabled
I believe this is due to the workaround
<Manager className="org.apache.catalina.session.PersistentManager" saveOnRestart="false"/>
Reading up the Tocat docs, they say "If you are using the Persistent Manager Implementation as described above, you MUST nest a <Store> element inside,...".
Adding a simple filebased store, i.e.
<Manager className="org.apache.catalina.session.PersistentManager" saveOnRestart="false">
<Store className="org.apache.catalina.session.FileStore"/>
</Manager>
solved that as well.
Adding the directory attribute and putting this on a clustered FS might help in clustering as well.
Eric Jain
added a comment - Yes, we are using Tomcat 5.5. Adding the "Manager" configuration element does seem to get rid of the error message. Would nevertheless be nice if it didn't appear with the default configuration...
Eric Jain
added a comment - Yes, we are using Tomcat 5.5. Adding the "Manager" configuration element does seem to get rid of the error message. Would nevertheless be nice if it didn't appear with the default configuration... Eric,
May I ask what version of Tomcat you are using? If it 5.5.x to avoid the error messages please add:
<Manager className="org.apache.catalina.session.PersistentManager" saveOnRestart="false"/>
to your configuration. See Step 5 of:
http://www.atlassian.com/software/jira/docs/latest/servers/tomcat55.html
Thanks,
Anton
Eric Jain
added a comment - This problem still seems to be around – not critical but annoying... 
Jeff Turner
added a comment - JRA-1909 same sort of problem as JRA-6452 I am testing the JIRA 3.0 Preview version and I think am still getting the same error.
I am running JIRA on Tomcat 5.
From Tomcat5's Catalina.out log:
"
Sep 4, 2004 5:27:42 PM org.apache.catalina.session.StandardManager doLoad
SEVERE: IOException while loading persisted sessions: java.io.WriteAbortedException: writing aborted; java.io.NotSerializableException: org.apache.log4j.Logger
java.io.WriteAbortedException: writing aborted; java.io.NotSerializableException: org.apache.log4j.Logger
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1278)
"
Jeff Turner
added a comment - > The "don't serialize sessions on tomcat restart" implies that JIRA can not be clustered,
Correct:
http://www.atlassian.com/software/jira/docs/latest/faq.html#clustering_support
and that seemless failover isn't even possible since users will have to login again correct?
Unless they have cookies enabled, in which case a new session is automatically established.
> While that's not cause for over-reaction, it does seem somewhat sub-optimal.
Yes, in time we aim to factor out the caching and use something pluggable like http://ehcache.sourceforge.net
> A note here states that its rescheduled for Jira 2.7, is that firm? Is there a release date planned for it?
Nope, it isn't scheduled for 3.0 - it will be up for consideration again for 3.1
Jeff Turner
added a comment - > The "don't serialize sessions on tomcat restart" implies that JIRA can not be clustered,
Correct:
http://www.atlassian.com/software/jira/docs/latest/faq.html#clustering_support
and that seemless failover isn't even possible since users will have to login again correct?
Unless they have cookies enabled, in which case a new session is automatically established.
> While that's not cause for over-reaction, it does seem somewhat sub-optimal.
Yes, in time we aim to factor out the caching and use something pluggable like http://ehcache.sourceforge.net
> A note here states that its rescheduled for Jira 2.7, is that firm? Is there a release date planned for it?
Nope, it isn't scheduled for 3.0 - it will be up for consideration again for 3.1
Mike Hardy
added a comment - Incidentally, not to shill for my own project, but I'll shill for my own project here (hey, its free) - I've worked with a colleague to write a filter that developers can use to provably detect these sorts of situations at development time.
Its called "ClusterCheck", and you can grab it at http://filterlib.sf.net
There are two other filters in filterlib that I won't stand behind at this date (they have known bugs) but ClusterCheck has been used in production at clients of ours and all known bugs are fixed.
It'll give you the stack trace of people that put non-serializable things in the session, and you can go from there. It will also detect people that modify things without calling setAttribute (breaks some clustering) and it can do aggregate and per-attribute size checks.
You guys should use it, and squish these things...
Mike Hardy
added a comment - Incidentally, not to shill for my own project, but I'll shill for my own project here (hey, its free) - I've worked with a colleague to write a filter that developers can use to provably detect these sorts of situations at development time.
Its called "ClusterCheck", and you can grab it at http://filterlib.sf.net
There are two other filters in filterlib that I won't stand behind at this date (they have known bugs) but ClusterCheck has been used in production at clients of ours and all known bugs are fixed.
It'll give you the stack trace of people that put non-serializable things in the session, and you can go from there. It will also detect people that modify things without calling setAttribute (breaks some clustering) and it can do aggregate and per-attribute size checks.
You guys should use it, and squish these things...
By the way, we're running Jira Ent 3.3.3