Bug 43174 - EOFException was thrown repeatedly from StandardManager
Summary: EOFException was thrown repeatedly from StandardManager
Status: RESOLVED WONTFIX
Alias: None
Product: Tomcat 6
Classification: Unclassified
Component: Catalina (show other bugs)
Version: 6.0.14
Hardware: Other other
: P2 normal (vote)
Target Milestone: default
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-08-21 05:33 UTC by Takayuki Kaneko
Modified: 2008-04-30 00:26 UTC (History)
0 users



Attachments
patch (4.24 KB, patch)
2007-08-21 09:36 UTC, Takayuki Kaneko
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Takayuki Kaneko 2007-08-21 05:33:06 UTC
Hi,

If SESSION.ser file was invalid, because Tomcat had been killed or something,
then EOFException would be thrown.
But StandardManager doesn't delete the invalid session file.
So if Tomcat is restarted, EOFException will be thrown repeatedly.

java.io.EOFException
	at java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2232)
	at
java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:2698)
	at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:750)
	at java.io.ObjectInputStream.<init>(ObjectInputStream.java:268)
	at
org.apache.catalina.util.CustomObjectInputStream.<init>(CustomObjectInputStream.java:57)
	at org.apache.catalina.session.StandardManager.doLoad(StandardManager.java:361)
	at org.apache.catalina.session.StandardManager.load(StandardManager.java:320)
	at org.apache.catalina.session.StandardManager.start(StandardManager.java:636)
	at org.apache.catalina.core.ContainerBase.setManager(ContainerBase.java:431)
	at org.apache.catalina.core.StandardContext.start(StandardContext.java:4130)
	at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:759)
	at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:739)
	at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:524)
	at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:904)
	at org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:867)
	at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:474)
	at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1112)
	at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:310)
	at
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
	at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1021)
	at org.apache.catalina.core.StandardHost.start(StandardHost.java:718)
	at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1013)
	at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:442)
	at org.apache.catalina.core.StandardService.start(StandardService.java:450)
	at org.apache.catalina.core.StandardServer.start(StandardServer.java:709)
	at org.apache.catalina.startup.Catalina.start(Catalina.java:551)
	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:585)
	at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:275)
	at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413)


I think StandardManager#doload should delete the session file after the
execution whether sucess or not.

I made a patch.

Regards,

Index: /tc6.0.x/trunk/java/org/apache/catalina/session/StandardManager.java
===================================================================
--- /tc6.0.x/trunk/java/org/apache/catalina/session/StandardManager.java
(revision 566663)
+++ /tc6.0.x/trunk/java/org/apache/catalina/session/StandardManager.java
(working copy)
@@ -345,6 +345,9 @@
             return;
         if (log.isDebugEnabled())
             log.debug(sm.getString("standardManager.loading", pathname));
+
+        try {
+
         FileInputStream fis = null;
         ObjectInputStream ois = null;
         Loader loader = null;
@@ -427,15 +430,17 @@
                 } catch (IOException f) {
                     // ignored
                 }
-
-                // Delete the persistent storage file
-                if (file != null && file.exists() )
-                    file.delete();
             }
         }
 
         if (log.isDebugEnabled())
             log.debug("Finish: Loading persisted sessions");
+
+        } finally {
+            // Delete the persistent storage file
+            if (file != null && file.exists() )
+                file.delete();
+        }
     }
Comment 1 Takayuki Kaneko 2007-08-21 09:36:39 UTC
Created attachment 20685 [details]
patch

I'm sorry. My patch has a problem about concurrency.
I reviced my patch.

Thanks.
Comment 2 Mark Thomas 2008-04-30 00:26:37 UTC
Deleting the file doesn't give a system admin any chance to examine it to see why it failed. We have seen serialisation bugs that this fix would make much harder to investigate.

The corrupted file will be over-written when Tomcat shutsdown so the exceptions will only be seen once anyway.