[infinispan-issues] [JBoss JIRA] (ISPN-2330) JBossMarshaller uses wrong class resolver after stop/start

[Scott Marlow (JIRA)]

    [ https://issues.jboss.org/browse/ISPN-2330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12726566#comment-12726566 ] 

Scott Marlow edited comment on ISPN-2330 at 10/15/12 1:25 PM:
--------------------------------------------------------------

Does the ExtendedRiverMarshaller have a similar problem?  That is what we appear to be using at the time of failure ("java.io.StreamCorruptedException: Unexpected byte found when reading an object: 50").  It is possible that I'm seeing a different issue.

The client side uses a ExtendedRiverMarshaller with a ContextClassResolver and the server side uses a ExtendedRiverMarshaller with a ModularClassResolver.

http://pastie.org/5063200 contains the a few lines from the attached server.log (zip)
                
      was (Author: smarlow):
    Does the ExtendedRiverMarshaller have a similar problem?  That is what we appear to be using at the time of failure.

The client side uses a ExtendedRiverMarshaller with a ContextClassResolver and the server side uses a ExtendedRiverMarshaller with a ModularClassResolver.

http://pastie.org/5063200 contains the a few lines from the attached server.log (zip)
                  
> JBossMarshaller uses wrong class resolver after stop/start
> ----------------------------------------------------------
>
>                 Key: ISPN-2330
>                 URL: https://issues.jboss.org/browse/ISPN-2330
>             Project: Infinispan
>          Issue Type: Bug
>          Components: Marshalling
>    Affects Versions: 5.1.4.FINAL
>            Reporter: Dennis Reed
>            Assignee: Galder Zamarreño
>            Priority: Critical
>              Labels: jdg, jdg6
>             Fix For: 5.2.0.CR1, 5.2.0.Final
>
>         Attachments: AS7clusteringtestServerLogs.zip
>
>
> org.infinispan.marshall.jboss.JBossMarshaller initializes the classResolver in its inject() method and clears it in its stop() method.
> If the cache is stopped and restarted (for example when redeploying a clustered web app in EAP), the wrong class resolver is used.
> Either the classResolver should not be removed in stop() (testing with it removed did not show any class leaking issues), or it should be reset in start().

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira