debug RMI NotSerializableException

[Shin]

Hello,

When you are doing RMI or other tasks involving Serialization of Java
objects, I guess you can run into "NotSerializableException". However,
this exception can happen while the serialization code is tranversing
some complicated object graph, so my question is: is there a quick way
to determine which field in which class actually causes this
NotSerializableException?

The stack trace only points to which class is not serializable, and
which RMI call the marshalling process is servicing. (In other words,
only the "head" and "tail", but lacks the most relevant information for
debugging purpose).

Thanks,
-Shin

 

[Thomas Hawtin]

Hello,

When you are doing RMI or other tasks involving Serialization of Java
objects, I guess you can run into "NotSerializableException". However,
this exception can happen while the serialization code is tranversing
some complicated object graph, so my question is: is there a quick way
to determine which field in which class actually causes this
NotSerializableException?

The stack trace only points to which class is not serializable, and
which RMI call the marshalling process is servicing. (In other words,
only the "head" and "tail", but lacks the most relevant information for
debugging purpose).

If your debugger wont give any cles, I would suggest either extending
ObjectOutputStream or downloading the latest Mustang snapshot and
setting the following property on the command line.

-Dsun.io.serialization.extendedDebugInfo=true

Clearly you are not the only person having this problem.

Tom Hawtin

 

[Shin]

Thanks for the pointer.

I tried 1.6.0 with the property set, no difference.

 

[jan V]

Thanks for the pointer.

I tried 1.6.0 with the property set, no difference.

This is probably not what you will want to hear, but you could write a
clever routine which, through Reflection, walks an object graph just like
the serialization engine does, and tells you which object is going to cause
serialization to fail. I've written something along those lines, as part of
a more generic tool commenting on various serializability issues.

 

[Thomas Hawtin]

Did you at least get an extra blank line in the exception trace/message?

This is probably not what you will want to hear, but you could write a
clever routine which, through Reflection, walks an object graph just like
the serialization engine does, and tells you which object is going to cause
serialization to fail. I've written something along those lines, as part of
a more generic tool commenting on various serializability issues.

That's not going to work with custom serialization. I haven't tried it,
but I would've thought(TM) that a cunning extension of
ObjectOutputStream could keep track of things.

 

[jan V]

serialization to fail. I've written something along those lines, as part
of

That's not going to work with custom serialization.

True.. never claimed it would ;-)

but I would've thought(TM) that a cunning extension of
ObjectOutputStream could keep track of things.

A cunning plan, he Baldrick? (sorry, can't resist)

 

[Shin]

Did you at least get an extra blank line in the exception trace/message?

This probably doesn't worth it, but here is the diff file from 5.0 and
6.0 with the property you mentioned set (assuming it's right, since
google return me nothing):

....@test> diff 5.0 6.0
1c1
< RMI service started: rmi://localhost/atPlace0 ActWrapperImpl@147ee05
---

RMI service started: rmi://localhost/atPlace0 ActWrapperImpl@dd5b

6c6
< at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:122)
---

at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:139)

22,36c22,36
< at
java.ibjectStreamClass.invokeWriteObject(ObjectStreamClass.java:890)
< at
java.ibjectOutputStream.writeSerialData(ObjectOutputStream.java:1333)
< at
java.ibjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1284)
< at
java.ibjectOutputStream.writeObject0(ObjectOutputStream.java:1073)
< at
java.ibjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1369)
< at
java.ibjectOutputStream.writeSerialData(ObjectOutputStream.java:1341)
< at
java.ibjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1284)
< at
java.ibjectOutputStream.writeObject0(ObjectOutputStream.java:1073)
< at
java.ibjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1369)
< at
java.ibjectOutputStream.writeSerialData(ObjectOutputStream.java:1341)
< at
java.ibjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1284)
< at
java.ibjectOutputStream.writeObject0(ObjectOutputStream.java:1073)
< at
java.ibjectOutputStream.writeObject(ObjectOutputStream.java:291)
< at sun.rmi.server.UnicastRef.marshalValue(UnicastRef.java:258)
< at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:117)
---

at java.ibjectStreamClass.invokeWriteObject(ObjectStreamClass.java:901)
at java.ibjectOutputStream.writeSerialData(ObjectOutputStream.java:1406)
at java.ibjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1337)
at java.ibjectOutputStream.writeObject0(ObjectOutputStream.java:1095)
at java.ibjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1454)
at java.ibjectOutputStream.writeSerialData(ObjectOutputStream.java:1419)
at java.ibjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1337)
at java.ibjectOutputStream.writeObject0(ObjectOutputStream.java:1095)
at java.ibjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1454)
at java.ibjectOutputStream.writeSerialData(ObjectOutputStream.java:1419)
at java.ibjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1337)
at java.ibjectOutputStream.writeObject0(ObjectOutputStream.java:1095)
at java.ibjectOutputStream.writeObject(ObjectOutputStream.java:313)
at sun.rmi.server.UnicastRef.marshalValue(UnicastRef.java:275)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:134)



That's not going to work with custom serialization. I haven't tried it,
but I would've thought(TM) that a cunning extension of
ObjectOutputStream could keep track of things.

Actually I can see jan's idea might work, it's just a little too heavy
weight in my case. However, assuming we can write this extension to
ObjectOutputStream, how can you hook it up to the RMI runtime system to
use your version?

And I don't think I get the cultural contex of this one (if there is
one):

A cunning plan, he Baldrick? (sorry, can't resist)

-Shin

 

[Thomas Hawtin]

This probably doesn't worth it, but here is the diff file from 5.0 and
6.0 with the property you mentioned set (assuming it's right, since
google return me nothing):

Odd. The 6.0 (b45) code in ObjectOutputStream looks obvious. Erm, sure
you have the property set? The property isn't getting removed for some
reason (server rewriting system properties, chaining new server process,
or something)?

Tom Hawtin