Object serialization failure during OutOfMemory error (EOFException)

Question

Hello all,
We are seeing a very strange situation when writing a serializable object to a flat file, specifically during an OutOfMemory condition. Our application saves the state of an object if an error occurs, and retries at a later point by reviving the object from its serialized form. We recently encountered a series of EOFExcetions when trying to reload the serialized object. Looking at the serialized data, we see that the file is indeed incomplete, and that it appears to be the serialized representation of the data contained within the object that is missing (the structure of the object appears to be stored in the serialized file, but not the runtime data).
The code that produces and consumes these serialized objects is used in a variety of locations, and even in the case where these EOF errors occurred usually works as expected. The difference appears to be that the error condition which lead to the object serialization was in-fact an OutOfMemory error. That is, we had an OOM error elsewhere in our application, which caused our objects to be serialized to disk. During this serialization process we end up with corrupt (incomplete) serialization data.
So.. the question is: Is it possible that the OutOfMemory situation causes the JVM to incorrectly serialize an object (without an error), and specifically to omit runtime data (variables) from the serialized form of the object?
Thanks/

Answer 1

jasonpolites wrote:
So.. the question is: Is it possible that the OutOfMemory situation causes the JVM to incorrectly serialize an object (without an error), and specifically to omit runtime data (variables) from the serialized form of the object?you're sure that the serialization process completed without an error? how do you know the the OOME did not cause the serialization to fail (because the serialization process itself will require more memory, hence if it is happening while the system is near the memory peak, it is likely to fail as well)? generally, when a jvm starts throwing OOME's all bets are off. failures in random places can easily cause the whole internal state of a system to become invalid.