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
