[JBoss JIRA] Created: (JGRP-674) ChannelFactory#createMultiplexerChannel bundled state transfer is not symmetric
8:33 p.m.
ChannelFactory#createMultiplexerChannel bundled state transfer is not symmetric
--------------------------------------------------------------------------------
Key: JGRP-674
URL: http://jira.jboss.com/jira/browse/JGRP-674
Project: JGroups
Issue Type: Bug
Reporter: Vladimir Blagojevic
Assigned To: Bela Ban
Channel createMultiplexerChannel(String stack_name, String id, boolean
register_for_state_transfer, String substate_id) throws Exception method should be invoked
on each cluster node. We have previously assumed that a user will invoke
createMultiplexerChannel with two parameters on a first cluster node and use 4 parameter
invocation on all other nodes. However, this approach is highly non-practical.
--
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
8:33 p.m.
New subject: [JBoss JIRA] Commented: (JGRP-674) ChannelFactory#createMultiplexerChannel bundled state transfer is not symmetric
[ http://jira.jboss.com/jira/browse/JGRP-674?page=comments#action_12396705 ]
Vladimir Blagojevic commented on JGRP-674:
------------------------------------------
Here is related comment by Brian Stansberry:
Passing register_for_state_transfer=true to the overloaded version of
JChannelFactory.createMultiplexerChannel still doesn't work properly. Not a big
priority for me, but FYI.
JBoss Messaging uses the overloaded version of JChannelFactory.createMultiplexerChannel
where they pass in a value for param register_for_state_transfer. They create 2 channels;
one where the value for the param *must* be false (see
http://jira.jboss.com/jira/browse/JBMESSAGING-1120 for earlier, now fixed, problem with
that and http://jira.jboss.com/jira/browse/JBAS-4909 for my workaround). For the other
channel a value of 'true' is legitimate (although not necessary, as this param is
a minor optimization that is of no value inside the AS).
Since JBMESSAGING-1120 is now fixed, I tried removing my JBAS-4909 workaround from the AS
and starting it. Fails with the following logging:
2008-01-20 12:23:20,164 WARN [org.jboss.messaging.core.impl.postoffice.GroupMember] Timed
out waiting for latch to be released
2008-01-20 12:23:20,165 WARN [org.jgroups.mux.Multiplexer] Failed multiple state transfer
under one flush phase
java.lang.Exception: Failed transfer for state id
DefaultPartition-JMS-CTRL::DefaultPartition-JMS, state provider was null
at org.jgroups.mux.Multiplexer.fetchServiceStates(Multiplexer.java:218)
at org.jgroups.mux.Multiplexer.getState(Multiplexer.java:170)
at org.jgroups.mux.MuxChannel.getState(MuxChannel.java:371)
at org.jgroups.mux.MuxChannel.getState(MuxChannel.java:345)
at org.jgroups.mux.MuxChannel.getState(MuxChannel.java:341)
at org.jboss.messaging.core.impl.postoffice.GroupMember.start(GroupMember.java:150)
at
org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.start(MessagingPostOffice.java:347)
at
org.jboss.messaging.core.jmx.MessagingPostOfficeService.startService(MessagingPostOfficeService.java:427)
at
org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:299)
at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:196)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:138)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
at
org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:140)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
at org.jboss.system.microcontainer.ServiceProxy.invoke(ServiceProxy.java:184)
at $Proxy5.start(Unknown Source)
at
org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:42)
at
org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:37)
at
org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
at
org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
at
org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
at
org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:327)
at
org.jboss.system.microcontainer.ServiceControllerContext.install(ServiceControllerContext.java:255)
at
org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1309)
at
org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:734)
at
org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:862)
at
org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:784)
at
org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:622)
at
org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:411)
at org.jboss.system.ServiceController.doChange(ServiceController.java:659)
at org.jboss.system.ServiceController.start(ServiceController.java:431)
at org.jboss.system.deployers.ServiceDeployer.start(ServiceDeployer.java:149)
at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:107)
at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:46)
at
org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:65)
at
org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
at
org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:169)
at
org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:853)
at
org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:874)
at
org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:794)
at
org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:327)
at
org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1309)
at
org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:734)
at
org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:862)
at
org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:784)
at
org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:622)
at
org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:411)
at
org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:498)
at
org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:506)
at
org.jboss.system.server.profileservice.ProfileServiceBootstrap.loadProfile(ProfileServiceBootstrap.java:245)
at
org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:131)
at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:408)
at org.jboss.Main.boot(Main.java:208)
at org.jboss.Main$1.run(Main.java:534)
at java.lang.Thread.run(Thread.java:595)
This fails on the startup of the 1st node. The underlying JChannel in question is not
shared; i.e. no other services have requested it.
This is not a big issue for me as I can just leave the JBAS-4909 workaround in place.
Setting register_for_statetransfer=true is of no real benefit in the AS anyway.
--
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry(a)redhat.com
ChannelFactory#createMultiplexerChannel bundled state transfer is not
symmetric
--------------------------------------------------------------------------------
Key: JGRP-674
URL: http://jira.jboss.com/jira/browse/JGRP-674
Project: JGroups
Issue Type: Bug
Reporter: Vladimir Blagojevic
Assigned To: Bela Ban
Channel createMultiplexerChannel(String stack_name, String id, boolean
register_for_state_transfer, String substate_id) throws Exception method should be invoked
on each cluster node. We have previously assumed that a user will invoke
createMultiplexerChannel with two parameters on a first cluster node and use 4 parameter
invocation on all other nodes. However, this approach is highly non-practical.
--
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
8:49 p.m.
New subject: [JBoss JIRA] Updated: (JGRP-674) ChannelFactory#createMultiplexerChannel bundled state transfer is not symmetric
[ http://jira.jboss.com/jira/browse/JGRP-674?page=all ]
Vladimir Blagojevic updated JGRP-674:
-------------------------------------
Fix Version/s: 2.6.2
2.7
Affects Version/s: 2.6
2.5
Assignee: Vladimir Blagojevic (was: Bela Ban)
ChannelFactory#createMultiplexerChannel bundled state transfer is not
symmetric
--------------------------------------------------------------------------------
Key: JGRP-674
URL: http://jira.jboss.com/jira/browse/JGRP-674
Project: JGroups
Issue Type: Bug
Affects Versions: 2.5, 2.6
Reporter: Vladimir Blagojevic
Assigned To: Vladimir Blagojevic
Fix For: 2.7, 2.6.2
Channel createMultiplexerChannel(String stack_name, String id, boolean
register_for_state_transfer, String substate_id) throws Exception method should be invoked
on each cluster node. We have previously assumed that a user will invoke
createMultiplexerChannel with two parameters on a first cluster node and use 4 parameter
invocation on all other nodes. However, this approach is highly non-practical.
--
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
8:49 p.m.
New subject: [JBoss JIRA] Commented: (JGRP-674) ChannelFactory#createMultiplexerChannel bundled state transfer is not symmetric
[ http://jira.jboss.com/jira/browse/JGRP-674?page=comments#action_12396706 ]
Vladimir Blagojevic commented on JGRP-674:
------------------------------------------
Resolved on HEAD:
Revision Changes Path
1.47 +8 -2 JGroups/src/org/jgroups/mux/MuxChannel.java
Resolved on 2.6 branch:
Revision Changes Path
1.38.2.6 +8 -2 JGroups/src/org/jgroups/mux/MuxChannel.java
ChannelFactory#createMultiplexerChannel bundled state transfer is not
symmetric
--------------------------------------------------------------------------------
Key: JGRP-674
URL: http://jira.jboss.com/jira/browse/JGRP-674
Project: JGroups
Issue Type: Bug
Affects Versions: 2.5, 2.6
Reporter: Vladimir Blagojevic
Assigned To: Bela Ban
Fix For: 2.7, 2.6.2
Channel createMultiplexerChannel(String stack_name, String id, boolean
register_for_state_transfer, String substate_id) throws Exception method should be invoked
on each cluster node. We have previously assumed that a user will invoke
createMultiplexerChannel with two parameters on a first cluster node and use 4 parameter
invocation on all other nodes. However, this approach is highly non-practical.
--
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
8:52 p.m.
New subject: [JBoss JIRA] Resolved: (JGRP-674) ChannelFactory#createMultiplexerChannel bundled state transfer is not symmetric
[ http://jira.jboss.com/jira/browse/JGRP-674?page=all ]
Vladimir Blagojevic resolved JGRP-674.
--------------------------------------
Resolution: Done
Adjusted MultiplexerStateTransferTest#testStateTransferWithRegistration to be symmetric.
ChannelFactory#createMultiplexerChannel bundled state transfer is not
symmetric
--------------------------------------------------------------------------------
Key: JGRP-674
URL: http://jira.jboss.com/jira/browse/JGRP-674
Project: JGroups
Issue Type: Bug
Affects Versions: 2.5, 2.6
Reporter: Vladimir Blagojevic
Assigned To: Vladimir Blagojevic
Fix For: 2.6.2, 2.7
Channel createMultiplexerChannel(String stack_name, String id, boolean
register_for_state_transfer, String substate_id) throws Exception method should be invoked
on each cluster node. We have previously assumed that a user will invoke
createMultiplexerChannel with two parameters on a first cluster node and use 4 parameter
invocation on all other nodes. However, this approach is highly non-practical.
--
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
6690
days inactive
6690
days old
4 comments
1 participants
participants (1)
-
Vladimir Blagojevic (JIRA)