[infinispan-dev] Infinispan 5.1.x Object marshalling with and without a class table in use and unmarshalling smacking its head against the wall...

Mon Oct 15 12:47:25 EDT 2012

On 10/15/2012 06:12 AM, Galder Zamarreño wrote:
> I've just realised this is the same issue Dennis reported in https://issues.jboss.org/browse/ISPN-2330
>
> @Ben, this should also solve your TorqueBox problem.
>
> I'll fix it today.

Didn't seem to help.  I attached server.log's to ISPN-2330, not that I 
expect them to be that useful directly (I don't have Infinispan trace 
logging enabled, just added my own INFO level output and various 
printlns also in infinispan/jboss-marshalling).

I'll send an update later when I have more information to share.

>
> On Oct 12, 2012, at 9:53 PM, Scott Marlow <smarlow at redhat.com> wrote:
>
>> http://pastie.org/5046919 shows the callstack for what looks like
>> creation of a new org.infinispan.marshall.jboss.ExtendedRiverMarshaller.
>>   Note that we also printed the instance for associated it with the
>> later marshalling problem
>> (this=org.infinispan.marshall.jboss.ExtendedRiverMarshaller at 869fb6d).
>>
>> I can see that we later use this same instance when we use the wrong
>> ClassResolver (org.jboss.marshalling.ContextClassResolver which comes
>> from the above marshaller).  http://pastie.org/5046962 shows the call
>> stack when we marshall with the ContextClassResolver instead of a
>> ModularClassResolver.
>>
>> Can we switch to also use the ModularClassResolver in the
>> http://pastie.org/5046919 callstack?
>>
>> On 10/12/2012 09:47 AM, Scott Marlow wrote:
>>> ReplicableCommandExternalizer.writeCommandParameters() can marshall an
>>> instance of class org.infinispan.util.ImmutableListCopy (as a
>>> ID_EXTERNALIZABLE_CLASS) fine.  If the classtable doesn't know about the
>>> org.infinispan.util.ImmutableListCopy class, we also marshall the AS7
>>> module name (org.infinispan) and module slot name (main).  The
>>> marshalled byte output looks something like the following (this is the
>>> successful case).  I apologize for the crappy hex/character dump :).
>>> Each hex value is preceded by '0x' and followed by an extra space separator.
>>>
>>> *class table does not have ImmutableListCopy class case*
>>> 0x03 0x01 0xFE 0x03 J0x00 0x00 0x11 0x00 0x00 0x00 0x1A
>>> default-host/distributable0xAE 0x01 0x03 0x01 0xFE 0x06 I0x02 0x03 '0x02
>>> ])0xDE +?>0x85 0xBF 0xEC 0xCD P0xCB 0x8E 20x9E 0xD0 K0x00 0x00 0x00 0x07
>>> 0x04 0x0A 0x00 0x00 0x00 %org.infinispan.util.ImmutableListCopy0x00 0x00
>>> 0x09 0xF0 0xBD 0x13 q0x06 >0x0E org.infinispan>0x04 main20x04 0x00 0x00
>>> 0x00 0x02 0x03 '0x02 ])0xDE +?>0x85 0xBF 0xEC 0xCD P0xCB 0x8E 20x9E 0xD0
>>> 0x03 '0x02 0xB4 0x0D 00x8C 0x98 0xCF M0x89 0xF1 d|}0x0A 0x0B 0xA3 0xCD
>>> 5K0x00 0x00 0x00 0x06 0x03 0x04 0x03 '0x02 ])0xDE +?>0x85 0xBF 0xEC 0xCD
>>> P0xCB 0x8E 20x9E 0xD0
>>>
>>> Notice that the "org.infinispan.util.ImmutableListCopy" (on middle of
>>> fourth line) is followed by about 10 separator bytes (of some importance
>>> I'm sure :).  After the 10 separator bytes, is the module name
>>> (org.infinispan) and that is followed by more separator bytes and then
>>> the module slot name (main).  Again, this is the *working case*.
>>>
>>>
>>> If the classtable does have an entry for the
>>> org.infinispan.util.ImmutableListCopy class,
>>> ReplicableCommandExternalizer.writeCommandParameters() appears to
>>> instead write out some binary values that unmarshalling won't know how
>>> to deal with later.  The hexdump for the *failing case* looks like:
>>>
>>> *class table does have ImmutableListCopy class case*
>>> 0x03 0x01 0xFE 0x03 J0x00 0x00 0x11 0x00 0x00 0x00
>>> Dorg.jboss.as.test.clustering.cluster.ejb3.stateful.bean.StatefulBean0x98 0x01
>>> 0x03 0x01 0xFE 0x06 I0x02 0x03 '0x02 0xD5 0xFD  0xCC 0xC7 0xFD 0x10 0xCC
>>> Q70xF7 0x9C %lZ5K0x00 0x00 0x00 0x14 0x04 0x0A 0x00 0x00 0x00
>>> %org.infinispan.util.ImmutableListCopy0x00 0x00 0x09 0xF0 0xBD 0x13
>>> q0x06 20x04 0x00 0x00 0x00 0x02 0x03 '0x02 H0xC6 0xD0 w0xEA 10xEA 0x97
>>> U0xDC 0xE6 0x1C B0x99 s0xF1 0x03 '0x02 0xD5 0xFD  0xCC 0xC7 0xFD 0x10
>>> 0xCC Q70xF7 0x9C %lZ55K0x00 0x00 0x00 0x13 0x03 0x04 0x03 '0x02 H0xC6
>>> 0xD0 w0xEA 10xEA 0x97 U0xDC 0xE6 0x1C B0x99 s0xF1
>>>
>>> In the above, the "org.infinispan.util.ImmutableListCopy" field is
>>> followed by various bytes but no module name.
>>>
>>> Later during when unmarshalling this payload, we reach code that doesn't
>>> understand how to unmarshall.  http://pastie.org/5043963 shows the
>>> failing callstack (partially below for your convenience).  It seems to
>>> me, that somewhere in unmarshalling (Object) code, we need to check if a
>>> class table was used and use the marshalled form instead.
>>>
>>> org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:751)
>>>
>>> org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
>>> org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:37)
>>> org.jboss.marshalling.ModularClassResolver.resolveClass(ModularClassResolver.java:101)
>>> org.jboss.marshalling.river.RiverUnmarshaller.doReadClassDescriptor(RiverUnmarshaller.java:938)
>>> org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1210)
>>> org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:272)
>>> org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
>>> org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:37)
>>> org.infinispan.marshall.exts.ReplicableCommandExternalizer.readParameters(ReplicableCommandExternalizer.java:158)
>>>
>>>
>>> This is recreating on the AS 7.1 branch, with jboss-marshalling 1.3.17.x
>>> and Infinispan 5.1.x.
>>>
>>> I'll get closer to understanding the problem, but I need to hear from
>>> the Infinispan champion of marshalling and class table handling.  So, I
>>> can coordinate effort with him/her.  I also wanted to share what we are
>>> seeing as well with the team.  :)
>>>
>>> Scott
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> --
> Galder Zamarreño
> galder at redhat.com
> twitter.com/galderz
>
> Project Lead, Escalante
> http://escalante.io
>
> Engineer, Infinispan
> http://infinispan.org
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>