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

[Scott Marlow]

Dennis,

Thanks for the help making sense of what is going on.

By the way, Galder's https://github.com/galderz/infinispan/tree/t_2330_5 
branch (which includes Dan Berindei's fix for ISPN-2297) fixed the issue.

Thanks to all that helped!

Scott

On 10/15/2012 08:29 PM, Dennis Reed wrote:
> 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