Better error reporting for FieldSerializer

[GoogleCodeExporter]

Right now, when there's an error during deserialization somewhere below 
FieldSerializer.readObjectData it's hard to tell what's the reason for the 
issue.

For debugging I deployed patched the FieldSerializer so that I was able to 
locate the issue.

The attached patch is a suggestion for an improvement.

Original issue reported on code.google.com by martin.grotzke on 26 May 2010 at 2:48

Attachments:

• FieldSerializer.java.patch

[GoogleCodeExporter]

If you have a deep object graph, for each level of the graph you will dump a 
message and a stacktrace. This can make it confusing to determine where the 
error really occurred.

Is the TRACE log level enough to debug serialization problems? Call 
"Log.TRACE();" to enable. FieldSerializer tells you what it is about to do, so 
if it fails you will know what field failed. Eg, with this logging you would 
know that the someOtherField field on the com.example.SomeClass is where the 
failure occurred:

...
00:00 TRACE: [kryo] Reading field: someIntField (com.example.SomeClass)
00:00 TRACE: [kryo] Read int: 1234
00:00 TRACE: [kryo] Reading field: someOtherField (com.example.SomeClass)
// Some exception and stacktrace.

Original comment by nathan.s...@gmail.com on 13 Aug 2010 at 10:08

[GoogleCodeExporter]

My case is an application running in production where in seldom cases 
deserialization fails. I can't enable tracing as this probably would kill the 
server, there are lots of requests. As operations is not under our control it's 
not so easy to enable trace for only one server, excluding it from load 
balancing and trying to reproduce the exceptional situation.
Therefore, if an error occurs I only have what's logged for this error (without 
trace being turned on).

What you say is correct: it would be better to log only the root cause and 
throw a custom exception that can be passed through (I have no access to my 
laptop until tomorrow evening so I can't do this right now). Still, also the 
provided patch would help me to debug deserialization errors.

Original comment by martin.grotzke on 14 Aug 2010 at 11:16

[GoogleCodeExporter]

Here's another patch that should print the exception only for the root cause.

I chose a kryo Context based solution as I could keep this "logic" as local as 
possible with this. With a custom RuntimeException (e.g. a subclass of 
SerializationException) wrapping the original exception (perhaps also a 
SerializationException?) other things might be affected. Also introducing an 
additional exception for this very special requirement seemed a little bit too 
much for me.

What do you think?

Original comment by martin.grotzke on 16 Aug 2010 at 10:56

Attachments:

• FieldSerializer.java.2.patch

[GoogleCodeExporter]

This issue was closed by revision r113.

Original comment by nathan.s...@gmail.com on 17 Aug 2010 at 4:35

• Changed state: Fixed

[GoogleCodeExporter]

You're right that more information is needed when trace isn't or can't be 
enabled. After some thought, I augmented SerializationException to allow 
arbitrary trace information to be appended. I updated Kryo and the object 
serializers to juggle exceptions properly to make use of this. As part of the 
exception message, you will now get a list of classes and fields that led up to 
the serialization or deserialization failure. Note that 3rd party serializers 
may not add trace info to the SerializationException.

Original comment by nathan.s...@gmail.com on 17 Aug 2010 at 4:40

[GoogleCodeExporter]

Issue 24 has been merged into this issue.

Original comment by nathan.s...@gmail.com on 17 Aug 2010 at 4:41