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

[Dennis Reed]

On 10/15/2012 06:56 PM, Scott Marlow wrote:
> All the better if I'm wrong, as we will solve both problems with one 
> fix.  :)
>
> I don't see it yet though.  I attached new logs to ISPN-2330 with a 
> little more information (clearer indication of when the problem is 
> caused in jbossas-clustering-SYNC-tcp-0/standalone/log/server.log).
>
> Both the ContextClassResolver and the ExtendedRiverMarshaller are 
> created well after the last JBossMarshalling.stop() occurred.  Also, 
> if we are creating a new ExtendedRiverMarshaller and using that when 
> this failure occurs, that should have nothing to do with any 
> JBossMarshaller instances.

The ExtendedRiverUnmarshaller may be new, but the configuration being 
passed into it is not.
(note: JBossMarshaller is the class that creates 
ExtendedRiver(Un)Marshallers and configures them)

Due to the bug, the old instance of JBossMarshaller is being used, where 
the class resolver was null'd out during stop(), which is why the 
ContextClassResolver (the default) is being used instead.

> Also note that the jbossmarshaller.stop() is only logged at the 
> beginning of the testsuite run and near the end (in 
> jbossas-clustering-SYNC-tcp-0/standalone/log/server.log).

It doesn't matter how far back in the log it was stopped.

Once the Infinispan cache has been stopped, due to this bug that same 
named cache can never be deployed again until the JVM is restarted
(or the entire Infinispan subsystem is restarted -- if everything using 
Infinispan is undeployed at once).

-Dennis