me0wster / javamelody

Automatically exported from code.google.com/p/javamelody
0 stars 0 forks source link

java.io.EOFException: Unexpected end of ZLIB input stream #226

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
In the web server logs I am seeing an EOFException (see below).
My guess is that an unexpected termination/kill of the application server 
process
(it's a development system - however, this may happen in production/qa aswell)
caused some files to be inconsistenly written.

The exception is persistent - an application server restart will not help.

[User ] exception while reading counters data from files in 
C:\Users\myuser\AppData\Local\Temp\javamelody\myapplication
java.io.EOFException: Unexpected end of ZLIB input stream
    at java.util.zip.InflaterInputStream.fill(InflaterInputStream.java:223)
    at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:141)
    at java.util.zip.GZIPInputStream.read(GZIPInputStream.java:92)
    at java.io.ObjectInputStream$PeekInputStream.read(ObjectInputStream.java:2265)
    at java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2278)
    at java.io.ObjectInputStream$BlockDataInputStream.readUTFBody(ObjectInputStream.java:3018)
    at java.io.ObjectInputStream$BlockDataInputStream.readUTF(ObjectInputStream.java:2819)
    at java.io.ObjectInputStream.readString(ObjectInputStream.java:1598)
    at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1319)
    at java.io.ObjectInputStream.readObject(ObjectInputStream.java:350)
    at java.util.HashMap.readObject(HashMap.java:1029)
    at sun.reflect.GeneratedMethodAccessor23.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
    at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1848)
    at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1752)
    at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328)
    at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1946)
    at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1870)
    at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1752)
    at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328)
    at java.io.ObjectInputStream.readObject(ObjectInputStream.java:350)
    at java.util.concurrent.ConcurrentHashMap.readObject(ConcurrentHashMap.java:1275)
    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:597)
    at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
    at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1848)
    at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1752)
    at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328)
    at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1946)
    at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1870)
    at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1752)
    at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328)
    at java.io.ObjectInputStream.readObject(ObjectInputStream.java:350)
    at net.bull.javamelody.CounterStorage.readFromFile(CounterStorage.java:105)
    at net.bull.javamelody.Counter.readFromFile(Counter.java:863)
    at net.bull.javamelody.Collector.<init>(Collector.java:94)
    at net.bull.javamelody.FilterContext.<init>(FilterContext.java:98)
    at net.bull.javamelody.MonitoringFilter.init(MonitoringFilter.java:98)
    at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:295)
    at org.apache.catalina.core.ApplicationFilterConfig.setFilterDef(ApplicationFilterConfig.java:422)
    at org.apache.catalina.core.ApplicationFilterConfig.<init>(ApplicationFilterConfig.java:115)
    at org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:4071)
    at org.apache.catalina.core.StandardContext.start(StandardContext.java:4725)
    at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053)
    at org.apache.catalina.core.StandardHost.start(StandardHost.java:840)
    at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053)
    at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:463)
    at org.apache.catalina.core.StandardService.start(StandardService.java:525)
    at org.apache.catalina.core.StandardServer.start(StandardServer.java:754)
    at org.apache.catalina.startup.Catalina.start(Catalina.java:595)
    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:597)
    at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:289)
    at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:414)

Original issue reported on code.google.com by mineral_...@gmx.de on 12 Jun 2012 at 11:10

GoogleCodeExporter commented 9 years ago
I realized that a clean shutdown of the tomcat actually caused that this 
exception is not shown anymore. It seems that this issue occurrs usually if the 
server is shutdown  ungracefully (e.g. killed).

Original comment by mineral_...@gmx.de on 17 Jun 2012 at 12:27

GoogleCodeExporter commented 9 years ago
Yes, this may happen if the server is killed just when writing some files, for 
example the statistics data of http requests for the current day.

It does hot have important impact, because:
- it is certainly rare to kill ungracefully the server in production or in QA
- it is even more rare that the server was writing those files at this moment
- if it happens, this does not block the restart of the server or the monitoring
- and it will be automatically solved, when the files are written again a 
minute after or when the server is gracefully shutdown
- if there was some lost data for that particular day, it will be replaced by 
some new data after some minutes or after some hours of monitoring

So this is rare and not really a problem when it happens.

Original comment by evernat@free.fr on 24 Jun 2012 at 1:28