Galder, I'll test the 5.1.x fix when its available. Thank you for looking into this issue.
Scott 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. > > On Oct 12, 2012, at 9:53 PM, Scott Marlow <[email protected]> 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@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 >>> [email protected] >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>> >> >> _______________________________________________ >> infinispan-dev mailing list >> [email protected] >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > -- > Galder Zamarreño > [email protected] > twitter.com/galderz > > Project Lead, Escalante > http://escalante.io > > Engineer, Infinispan > http://infinispan.org > > > _______________________________________________ > infinispan-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/infinispan-dev > _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
