[jboss-jira] [JBoss JIRA] Closed: (JGRP-418) MuxChannel.getState() always returns false with StreamingStateTransfer protocol

[Jerry Gauthier (JIRA)]

     [ http://jira.jboss.com/jira/browse/JGRP-418?page=all ]

Jerry Gauthier closed JGRP-418.
-------------------------------

    Resolution: Cannot Reproduce Bug

Vladimir suggested that this problem might be caused by ClusterPartition failing to close the input stream when setting its state.  I modified ClusterPartition (see JBAS-3515) to close the stream.  I am now unable to reproduce the problem reported in JGRP-418 so it appears that the problem was  caused by the ClusterPartition implementation.  

> MuxChannel.getState() always returns false with StreamingStateTransfer protocol
> -------------------------------------------------------------------------------
>
>                 Key: JGRP-418
>                 URL: http://jira.jboss.com/jira/browse/JGRP-418
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.4.1
>            Reporter: Jerry Gauthier
>         Assigned To: Vladimir Blagojevic
>
> When I execute DRMTestCase.testIsMasterReplica() in JBossAS 5.0 using the StreamingStateTransfer protocol, MuxChannel.getState() always returns false.  This method is invoked from ClusterPartition.fetchState(); it returns false even though debugging the other node in a two node cluster shows that the state has been retrieved.  If I use the StateTransfer protocol instead, the transfer is successful.
> I started debugging this issue and determined that ClusterPartition never successfully retrieves state from the multiplexer channel when using StreamingStateTransfer.  It's possible that the problem lies in ClusterPartition but this can't be determined until it's understood why getState() is returning false.
> This problem can be replicated as follows.
> 1)  Ensure that you're using the latest JBossAS 5.0.0 HEAD cluster and testsuite\cluster code as I made recent changes in this area.
> 2) Modify ..\cluster\output\resources\jgroups-multiplexer.sar\META-INF\multiplexer-stacks.xml.  Change the "tunnel" stack to use StreamingStateTransfer instead of StateTransfer.  This is the stack used by the test in DRMTestCase.testIsMasterReplica().
> 3)  Running the test should show the following result.
>     <error message="Initial serviceState transfer failed: Channel.getState() returned false" type="java.lang.IllegalStateException">java.lang.IllegalStateException: Initial serviceState transfer failed: Channel.getState() returned false
> 	at org.jboss.ha.framework.server.ClusterPartition.fetchState(ClusterPartition.java:511)
> 	at org.jboss.ha.framework.server.ClusterPartition.startService(ClusterPartition.java:335)
> 	at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
> 	at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:196)
> 	at org.jboss.test.cluster.test.DRMTestCase.testIsMasterReplica(DRMTestCase.java:686)
> 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
> 	at junit.extensions.TestSetup.run(TestSetup.java:23)
> </error>
> 4)  Note: DRMTestCase.testIsMasterReplica() won't execute successfully with the StateTransfer protocol until JGRP-416 is resolved.  This issue causes JGroups to issue UnsupportedOperationException for UnmodifiableVector during the merge process in the test case.  I've patched the problem in JGroups locally and confirmed that the test does run successfully for StateTransfer after this issue is resolved.  It's not necessary to patch JGRP-416 to investigate MuxChannel.getState() as the state problem occurs before the UnmodifiableVector problem.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira