Better error reporting for FieldSerializer about kryo HOT 6 CLOSED

From [email protected] on August 13, 2010 15:08:35

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.

from kryo.

From martin.grotzke on August 14, 2010 04:16:12

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.

from kryo.

From martin.grotzke on August 16, 2010 15:56:36

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?

Attachment: FieldSerializer.java.2.patch

from kryo.

From [email protected] on August 16, 2010 21:35:56

This issue was closed by revision r113.

Status: Fixed

from kryo.

From [email protected] on August 16, 2010 21:40:13

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.

from kryo.

From [email protected] on August 16, 2010 21:41:15

Issue 24 has been merged into this issue.

from kryo.