incubator-yoko-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <>
Subject Re: Strange marshaling problem.
Date Wed, 13 Dec 2006 17:45:24 GMT
Just a guess, but are some of the arrays reused? Basically, are they  
serializing the exact same array instance twice in the same request  
(or object stream)?  If so, it could be a back reference.

Again, just a guess...


On Dec 13, 2006, at 9:27 AM, Rick McGuire wrote:

> Oops, never mind the previous.  The test case is populating the  
> integers using nested loops and using values of (i*j) for the  
> insertions.  The numbers I'm seeing are the correct sequence.  The  
> input stream seems to be carrying extra unexpected values.  This is  
> even more evidence that things are working correctly up to the  
> failure point.
> Rick
> Rick McGuire wrote:
>> Ok, I've figured out something a little more here.  By checking  
>> the values of the unmarshalled Integer objects, I've discovered  
>> that on the array where the error occurs, the unmarshalling is  
>> somehow skipping values.  The first object read is ok, the second  
>> object should be third, the 3rd object is the 5th, and the 4th  
>> read ends up giving the error.  Any suggestions on what could  
>> suddenly cause values to start getting skipped like this, or where  
>> I can try probing to find the cause of the error?
>> Rick
>> Rick McGuire wrote:
>>> I'm working on a fairly complicated test case that involves  
>>> sending and receiving a very large object across RMI.  The object  
>>> in question is a 3-dimensional array of Vectors.  The Vectors are  
>>> all 5 elements in size, each element consisting of an Integer  
>>> instance.  There were a number of problems I needed to fix first  
>>> in array handling, but things appear to be working correctly  
>>> now.  The Vectors appear to be deserializing correctly.  Each one  
>>> contains an Object array that appears to be the correct size.
>>> The Integers are getting deserialized ok, until around the 50th  
>>> or so value is read from the stream.  At that point, I'm getting  
>>> a MARSHAL exception for an invalid value type code.  The bogus  
>>> value is 0x3800.  I don't know here this value came from, since  
>>> the serialized object was generated by a Sun RMI server.  Does  
>>> this value have an special meaning to anybody?  Is it possibly a  
>>> chunking marker, or is something else going on here?
>>> Rick

View raw message