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 _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
