incubator-yoko-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick McGuire <rick...@gmail.com>
Subject Re: Strange marshaling problem.
Date Wed, 13 Dec 2006 21:47:17 GMT
Ok, I finally got this problem sorted out, and it was a nasty one.  The 
root of the problem was code in InputStream.readTypeCodeImpl(), and it 
was very subtle.  This code was doing the following:

   1. Calling read_ulong() to read the kind information for the type code.
   2. Saving the current buffer position - 4 in the variable oldPos.  
      This position is the buffer position of the start of the typecode.
   3. In the switch statement for the various type codes, read_ulong()
      was called again to retrieve an encapsulation length.
   4. An id string for the cache was read using read_string().
   5. checkCache() was called to see if this type had been encountered
      before.  If it had, then the buffer read position was placed at
      "oldPos + 8 + length", skipping over the entire type code and just
      using the value from the cache.

This was failing because the type code (read in step 1) and the 
encapsulation length (read in step 3) are on opposite sides of a chunk 
boundary.  When a type is reused, checkCache is positioning the buffer 
pointer 4 bytes short of where it needed to be, thus messing everything 
up. 

I was able to fix this by moving the pointer relative to the start of 
the encapsulation length, rather than the beginning of the entire type 
code.  Based on what I've been seeing for chunk sizes, I'm reasonable 
confident that all of the type information from that point on will be 
contained in a single chunk.  In any event, this test case is now 
finally working.

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
>



Mime
View raw message