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
