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...
6:56 p.m.
On 10/15/2012 06:07 PM, Dennis Reed wrote:
On 10/15/2012 04:21 PM, Scott Marlow wrote:
> On 10/15/2012 12:47 PM, Scott Marlow wrote:
>> On 10/15/2012 06:12 AM, Galder Zamarreño wrote:
>>> I've just realised this is the same issue Dennis reported in
>>> https://issues.jboss.org/browse/ISPN-2330
>>>
>>> @Ben, this should also solve your TorqueBox problem.
>>>
>>> I'll fix it today.
>>
>> Didn't seem to help. I attached server.log's to ISPN-2330, not that I
>> expect them to be that useful directly (I don't have Infinispan trace
>> logging enabled, just added my own INFO level output and various
>> printlns also in infinispan/jboss-marshalling).
>>
>> I'll send an update later when I have more information to share.
>
>
> For my issue, stop/start methods don't appear to be involved.
> http://pastebin.com/QiGV7F3b shows us creating a new
> ExtendedRiverMarshaller/ContextClassResolver pair which is soon used
> for marshalling.
The stop method is involved.
Your logs attached to the JIRA show the error start happening when you
redeploy your war.
During the undeploy it calls JBossMarshaller.stop, then during the
deploy it gets the error because of the wrong class resolver.
> I do see some calls to JBossMarshaller.stop() during my testing but
> that is very early in the test run (well before any of this occurs and
> well after the failures occur).
>
> I'll stop commenting on ISPN-2330, since my issue appears to be
> different.
It's not different. You are hitting ISPN-2330.
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.
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).
Also note that the class resolver is not the only issue that prevents a
clustered .war or EJB to be redeployed in EAP6.
There's also an issue with state transfer (which may be related to the
same underlying cause -- both issues appear to be from re-using the
wrong component that was already stopped).
-Dennis
7:29 p.m.
New subject: 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
10:29 a.m.
New subject: Infinispan 5.1.x Object marshalling with and without a class table in use and unmarshalling smacking its head against the wall...
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
4454
days inactive
4455
days old
infinispan-dev@lists.jboss.org
2 comments
2 participants
participants (2)
-
Dennis Reed -
Scott Marlow