Can't write session to disk with tomcat : Servlet is destroyed before
serialization
-----------------------------------------------------------------------------------
Key: WICKET-3470
URL: https://issues.apache.org/jira/browse/WICKET-3470
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 1.5-RC1
Environment: Windows 7 x64
apache-tomcat-6.0.32-windows-x86
(Running from Eclipse view, Faceted project)
Reporter: SegFault
Hi,
When I stop my tomcat, I have the following error :
GRAVE: Exception au déchargement des sessions vers le stockage persistant
(persistent storage)
java.lang.IllegalStateException: PageManager for application wicket not
registered.
at
lm.lbx.application.PersistentPageManager$SessionEntry.getPageStore(PersistentPageManager.java:86)
at
lm.lbx.application.PersistentPageManager$SessionEntry.writeObject(PersistentPageManager.java:197)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at java.io.ObjectStreamClass.invokeWriteObject(Unknown Source)
at java.io.ObjectOutputStream.writeSerialData(Unknown Source)
at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown Source)
at java.io.ObjectOutputStream.writeObject0(Unknown Source)
at java.io.ObjectOutputStream.writeObject(Unknown Source)
at
org.apache.catalina.session.StandardSession.writeObject(StandardSession.java:1561)
at
org.apache.catalina.session.StandardSession.writeObjectData(StandardSession.java:1004)
at
org.apache.catalina.session.StandardManager.doUnload(StandardManager.java:528)
at
org.apache.catalina.session.StandardManager.unload(StandardManager.java:469)
at
org.apache.catalina.session.StandardManager.stop(StandardManager.java:678)
at
org.apache.catalina.core.StandardContext.stop(StandardContext.java:4875)
at org.apache.catalina.core.ContainerBase.stop(ContainerBase.java:1106)
at org.apache.catalina.core.ContainerBase.stop(ContainerBase.java:1106)
at org.apache.catalina.core.StandardEngine.stop(StandardEngine.java:468)
at
org.apache.catalina.core.StandardService.stop(StandardService.java:604)
at org.apache.catalina.core.StandardServer.stop(StandardServer.java:788)
at org.apache.catalina.startup.Catalina.stop(Catalina.java:662)
at org.apache.catalina.startup.Catalina.start(Catalina.java:629)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:289)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:414)
After a little digging, it's because tomcat first unload the servlet mapping
and destroy the servlet, and then, ask for serialization. I'm not sure it's a
wiket bug, tell me if i have to report it against tomcat.
Here is the trace of the destroy :
Thread [main] (Suspended (breakpoint at line 357 in PersistentPageManager))
PersistentPageManager.destroy() line: 357
PageAccessSynchronizer$1(PageManagerDecorator).destroy() line: 86
LibellexApplication(Application).internalDestroy() line: 658
LibellexApplication(WebApplication).internalDestroy() line: 470
WicketFilter.destroy() line: 456
ApplicationFilterConfig.release() line: 357
StandardContext.filterStop() line: 4106
StandardContext.stop() line: 4869
StandardHost(ContainerBase).stop() line: 1106
StandardEngine(ContainerBase).stop() line: 1106
StandardEngine.stop() line: 468
StandardService.stop() line: 604
StandardServer.stop() line: 788
Catalina.stop() line: 662
Catalina.start() line: 629
NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not
available [native method]
NativeMethodAccessorImpl.invoke(Object, Object[]) line: not available
DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: not
available
Method.invoke(Object, Object...) line: not available
Bootstrap.start() line: 289
Bootstrap.main(String[]) line: 414
And the trace requesting serialization :
Thread [main] (Suspended (breakpoint at line 83 in
PersistentPageManager$SessionEntry))
PersistentPageManager$SessionEntry.getPageStore() line: 83
PersistentPageManager$SessionEntry.writeObject(ObjectOutputStream)
line: 197
NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not
available [native method]
NativeMethodAccessorImpl.invoke(Object, Object[]) line: not available
DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: not
available
Method.invoke(Object, Object...) line: not available
ObjectStreamClass.invokeWriteObject(Object, ObjectOutputStream) line:
not available
ObjectOutputStream.writeSerialData(Object, ObjectStreamClass) line: not
available
ObjectOutputStream.writeOrdinaryObject(Object, ObjectStreamClass,
boolean) line: not available
ObjectOutputStream.writeObject0(Object, boolean) line: not available
ObjectOutputStream.writeObject(Object) line: not available
StandardSession.writeObject(ObjectOutputStream) line: 1561
StandardSession.writeObjectData(ObjectOutputStream) line: 1004
StandardManager.doUnload() line: 528
StandardManager.unload() line: 469
StandardManager.stop() line: 678
StandardContext.stop() line: 4875
StandardHost(ContainerBase).stop() line: 1106
StandardEngine(ContainerBase).stop() line: 1106
StandardEngine.stop() line: 468
StandardService.stop() line: 604
StandardServer.stop() line: 788
Catalina.stop() line: 662
Catalina.start() line: 629
NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not
available [native method]
NativeMethodAccessorImpl.invoke(Object, Object[]) line: not available
DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: not
available
Method.invoke(Object, Object...) line: not available
Bootstrap.start() line: 289
Bootstrap.main(String[]) line: 414
Well at this time, a simple dirty hack is to bypass destroy chain to avoid
removal of app from managers properties of class PersistentPageManager. But I
would like to have a real clean solution.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
