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