[Spread-users] deserialization problem on unix?

Rod Fleischer rodf at sparta.com
Wed May 21 13:28:05 EDT 2003


Ryan,

Thanks for your efforts to send me the windows executable last night, 
the problem is the damned corporate firewall.  Oh well, I appreciate the 
attempt...  I would have preferred to test with spread on windows since 
that's where we're usually running it for our tests.

In any case...  I put my code back to using get/setObject and verified 
that it didn't work under spread 3.17.0 with the spread daemon running 
on linux.  I patched the source accordingly and recompiled it and tried 
again, same error, no difference.

spread.SpreadException: readObject(): java.lang.ClassNotFoundException: 
com.sparta.network.MulticastMessage

So I'm back to my workaround doing the de/serialization calls myself, 
but I'm happy to continue testing your beta stuff against this problem 
should you so desire.

-Rod


Ryan Caudy wrote:
> We are getting close to releasing version 3.17.1 of spread, and one of 
> the changes that will be included might help with this problem.  I've 
> attached a patch to be applied to the spread source file session.c that 
> will update it accordingly.  Please let us know if this helps.
> 
> --Ryan
> 
> Rod Fleischer wrote:
> 
>>
>>
>> Daniel Rall wrote:
>>
>>
>>> Right, but it's easy to have the definitions of the class differ between
>>> hosts, so that the bytecodes on one side of the network connection are
>>> slightly different than the bytecodes on the other side.  Since you 
>>> mounted the same file system for use by both hosts, this seems 
>>> unlikely (especially since you even diffed the serialized data).
>>
>>
>>
>>
>> Agreed.  This is one of the reasons that I'm doing it via smbmount. 
>> (The other being that I don't have to copy object code across after a 
>> recompile.)
>>
>>
>>> I'd try upping the XP version to _02 (assuming it's available).  I'd 
>>> also 
>>
>>
>>
>> done.  no difference.
>>
>>> For a narrower test case, I suggest open a TCP socket connection 
>>> between your Linux and XP hosts, and writing a serialized 
>>> com.sparta.network.spread.Foo object across it.  If you can 
>>> deserialize on the Linux side, there may be a problem in that 
>>> internal_receive() method of  the SpreadConnection class.  If you 
>>> still can't deserialize, the problem is somewhere in the JVM, 
>>> library, envrionment, or OS level.
>>
>>
>>
>>
>> Tried this.  Will include source below.  Without spread, it worked 
>> just fine.  Linux side deserialized without any problem.  This 
>> suggests to me that the problem is in fact in spread somewhere.  I 
>> don't understand why there's a problem with the same serialized data 
>> on both sides, but with spread removed from the picture it works...
>>
>> Any idea what the likelihood of a fix in the near future would be?
>>
>> If I can provide any further analysis, please let me know.
>>
>> -Rod
>>
>>
> 
> ------------------------------------------------------------------------
> 
> --- daemon/session.c	2003-04-18 13:13:09.000000000 -0400
> +++ session.c.patched	2003-05-20 16:29:15.000000000 -0400
> @@ -1153,6 +1153,7 @@
>  	int             len, remain, ret;
>          int             head_size, data_frag_len;
>          int             ses, ioctl_cmd;
> +        char            *head_buf;
>  #if 0
>  #ifndef ARCH_SCATTER_NONE
>  static  struct  msghdr  msgh;
> @@ -1187,6 +1188,7 @@
>  
>          msg = Sessions[ses].read_mess;
>  	head_ptr = Message_get_message_header(msg);
> +        head_buf = (char*)head_ptr;
>          head_size = Message_get_header_size();
>  
>          /* set file descriptor to non blocking */
> @@ -1198,7 +1200,7 @@
>                  /* read up to size of message_header */
>                  len = Sessions[ses].read.cur_byte;
>                  remain = sizeof(message_header) - len;
> -                ret = recv( mbox, (char *) &head_ptr[len], remain, 0 );
> +                ret = recv( mbox, (char *) &head_buf[len], remain, 0 );
>                  if( ret  == remain )
>                  {
>                          Sessions[ses].read.cur_byte += ret;


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