[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