Re: [infinispan-dev] Infinispan 5.1.x Object marshalling with and without a class table in use and unmarshalling smacking its head against the wall...
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