Exception loading sessions from persistent storage
Java.io.EOFException
at java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2228)
at java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:2694)
at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:761)
at java.io.ObjectInputStream.<init>(ObjectInputStream.java:277)
at org.apache.catalina.util.CustomObjectInputStream.<init>(CustomObjectInputStream.java:56)
at org.apache.catalina.session.StandardManager.doLoad(StandardManager.java:384)
at org.apache.catalina.session.StandardManager.load(StandardManager.java:343)
at org.apache.catalina.session.StandardManager.start(StandardManager.java:657)
at org.apache.catalina.core.ContainerBase.setManager(ContainerBase.java:499)
at org.apache.catalina.startup.ContextConfig.managerConfig(ContextConfig.java:315)
at org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:635)
at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:216)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:4290)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:823)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:807)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:595)
at org.apache.catalina.core.StandardHostDeployer.install(StandardHostDeployer.java:277)
at org.apache.catalina.core.StandardHost.install(StandardHost.java:832)
at org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:701)
at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:432)
at org.apache.catalina.startup.HostConfig.start(HostConfig.java:983)
at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:349)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1091)
at org.apache.catalina.core.StandardHost.start(StandardHost.java:789)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1083)
at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:478)
at org.apache.catalina.core.StandardService.start(StandardService.java:480)
at org.apache.catalina.core.StandardServer.start(StandardServer.java:2313)
at org.apache.catalina.startup.Catalina.start(Catalina.java:556)
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:287)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:425)
分析: session未超时的情况下,服务器关闭的时候会被序列化为工程名\SESSIONS.ser,tomcat 启动的时候再加载进来,EOFException表示tomcat上次关闭时还有一些活动连接,所以在重启时tomcat尝试去恢复这些session,但是在输入过程中意外地到达文件尾或流尾的信号,导致从session中获取数据失败。异常是tomcat本身的问题,由于tomcat上次非正常关闭时有一些活动session被持 久化(表现为一些临时文件),在重启时,tomcat尝试去恢复这些session的持久化数据但又读取失败造成的。此异常不影响系统的使用。
解决办法:将 tomcat_home\work\Catalina\localhost\『工程名』\SESSIONS.ser删除。如果正常关闭服务端,该文件是自 动删除的。考虑到每个人的tomat的工作目录不同,建议在“搜索”功能中找到你的SESSIONS.ser文件,而且只需要删 除..\yourProjectName\下的SESSIONS.ser即可。
最简单的办法是work下的全部删除,然后重启tomcat。
下面是有关tomcat 的work目录的知识:
1 用tomcat作web服务器的时候,部署的程序在webApps下,这些程序都是编译后的程序(发布到tomcat的项目里含的类,会被编译成.class后才发布过来,源文件没有发布过来,但这里的jsp没有经编译的)。tomcat有一个work目录,里面存放了页面的缓存,访问的jsp都会编译(从work里进入Catalina后的如localhost站点文件夹下的项目,我们可以看到那些jsp 页面会被编译成应该是servlet文件,下次再来访问时,就直接运行servlet类就可以向客户端反应响应页面了,所以有的博客说第一次访问时会比较 慢,是因为新发布上去的页面在第一个人访问时,会先编译成servlet文件,所以慢了,一旦编译好,那么除非jsp页面修改,不然下次访问直接运行 servlet就可以响应用户,所以快),编译后的文件都会存储在work目录下。而tomcat显示的目录,都会从这个缓存里找编译后的jsp对应的class文件。所以当清空了work目录后,该过程将会从新来过。
有的时候会遇到一个问题,就是修改后的页面在tomcat运行的时候显示不了修改后的痕迹。这个时候删除work目录下对应的项目文件夹,重新启动tomcat就可以了。
2 在tomcat的conf配置文件夹下的server.xml文件里配置了Host name后,就会在conf下的Catalina文件夹和work下的Catalina文件下建立站点名称的文件夹,项目每次发布都会放入来,也会记录到conf下的Catalina文件夹的配置文件里去。
from:http://blog.csdn.net/lxlzhn/article/details/8685687