debug RMI NotSerializableException

Thread view:

Shin - 02 Aug 2005 21:25 GMT

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

Reply to this Message

Thomas Hawtin - 02 Aug 2005 21:40 GMT

> Hello,
>
[quoted text clipped - 9 lines]
> 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

Signature

Unemployed English Java programmer
http://jroller.com/page/tackline/

Reply to this Message

Shin - 02 Aug 2005 22:07 GMT

Thanks for the pointer.

I tried 1.6.0 with the property set, no difference.

Reply to this Message

jan V - 02 Aug 2005 22:50 GMT

> 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.

Reply to this Message

Thomas Hawtin - 02 Aug 2005 23:16 GMT

>>Thanks for the pointer.
>>
>>I tried 1.6.0 with the property set, no difference.

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.

Signature

Unemployed English Java programmer
http://jroller.com/page/tackline/

Reply to this Message

jan V - 02 Aug 2005 23:43 GMT

> > 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.

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)

Reply to this Message

Shin - 03 Aug 2005 19:14 GMT

> >>I tried 1.6.0 with the property set, no difference.
>
> 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.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:890)
< at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1333)
< at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1284)
< at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1073)
< at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1369)
< at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1341)
< at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1284)
< at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1073)
< at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1369)
< at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1341)
< at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1284)
< at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1073)
< at
java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:291)
< at sun.rmi.server.UnicastRef.marshalValue(UnicastRef.java:258)
< at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:117)
---

> at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:901)
> at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1406)
[quoted text clipped - 11 lines]
> at sun.rmi.server.UnicastRef.marshalValue(UnicastRef.java:275)
> at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:134)

> > 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
[quoted text clipped - 5 lines]
> 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):

>> 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

Reply to this Message

Thomas Hawtin - 03 Aug 2005 19:28 GMT

>>>>I tried 1.6.0 with the property set, no difference.
>>
[quoted text clipped - 3 lines]
> 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

Signature

Unemployed English Java programmer
http://jroller.com/page/tackline/

Reply to this Message

debug RMI NotSerializableException

Free Magazines