[Spread-users] deserialization problem on unix?
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