[infinispan-dev] Infinispan 5.1.x Object marshalling with and without a class table in use and unmarshalling smacking its head against the wall...

[Scott Marlow]

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
>