[Spread-users] deserialization problem on unix?

Rod Fleischer rodf at sparta.com
Thu May 15 15:50:21 EDT 2003

Jonathan Stanton wrote:
> This looks really wierd.

Tell me about it.

> If you have a tiny separate program that can read a serialized object
> from a file and try to instantiate it. Does that work with the file the
> linux machine received? (one would think it would since it is the 'same'
> file in bits as the one the Windows machine generated) Does it work if
> the linux 'file' is read and instantiated on a windows machine?

Good idea.  I hacked up a little test and tried this...

Yes, the linux machine can read the file that the windows machine 
'sent'.  The windoes machine can read the file that the linux machine 
'sent'.  Spread is not involved in this test.

I hacked up another test, in which I generated a closer test to my real 
world scenario.  I had been trying to send a MulticastMessage object 
(the object by which our application wraps all data for transport) via 
Spread, so I wrote a test which built one and serialized it and sent via 
java socket connection with no problem.

I then made a change to my real world code where I serialized the 
MulticastMessage object myself and passed a byte array to 
SpreadMessage.setData instead of setObject, and vice versa on the 
reverse side.  It worked perfectly.

This suggests to me that SpreadMessage has issues of some kind with 
object serialization.  Again, I'm using the same spread code, the 
spread.jar file in question is in the filesystem used by the windows 
side, which is smbmounted onto the linux side, and symlinked from the 
java extension directory.

I have no idea what it could be, I'm making exactly the same calls that 
the SpreadMessage get/setObject methods do.  But if I issue those calls 
myself outside of Spread, it works fine.  If I rely on Spread to make 
those calls, it fails.

(Ever get the impression that your job could be replaced by a voodoo 
shaman doing a rain dance and waving around a dead chicken?)

>>From the network perspective, if Spread is delivering the exact same
> bytes as it was given on the sender side, then nothing is wrong with the
> internals of Spread. 

I would agree with you, except for the fact that this works just fine as 
long as Spread isn't relied upon for object de/serialization.

> Since, as you say, the class can clearly be found since it sends just
> fine, is there any lower-level JVM debugging you can enable that will
> provide more information about what's failing inside the JVM? 

Uh.. I have no idea how to do that.  Any suggestions would be very much 



Rod Fleischer          Senior Engineer          SPARTA, Inc.
410.872.1515.x241      410.872.8079 (fax)       rodf at sparta.com

More information about the Spread-users mailing list