[jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)] - Re: Changes on the JBM stack on JBoss5

[clebert.suconic@jboss.com]

anonymous wrote : I am not familiar with message ordering 

If you are saying that because of the latest testsuite that failed on Hudson, this error don't have anything to do with message-ordering. Last run it happened on the message ordering test, but it could happen on any clustered test on JBM.

anonymous wrote :  am not familiar with ....  state semantics that have to be satisfied


When we start JBM, we aways get the state from the cluster on the jbm-control channel.


Look at GroupMember.start method (on the JBM tree):


  |    public void start() throws Exception
  |    {		
  |    	this.controlChannel = jChannelFactory.createControlChannel();
  |    	
  |       this.dataChannel = jChannelFactory.createDataChannel();
  |       
  |       // We don't want to receive local messages on any of the channels
  |       controlChannel.setOpt(Channel.LOCAL, Boolean.FALSE);
  | 
  |       dataChannel.setOpt(Channel.LOCAL, Boolean.FALSE);
  |       
  |       MessageListener messageListener = new ControlMessageListener();
  |       
  |       MembershipListener membershipListener = new ControlMembershipListener();
  |       
  |       RequestHandler requestHandler = new ControlRequestHandler();
  |       
  |       dispatcher = new MessageDispatcher(controlChannel, messageListener, membershipListener, requestHandler, true);
  |       	      
  |       Receiver dataReceiver = new DataReceiver();
  |       
  |       dataChannel.setReceiver(dataReceiver);
  |       
  |       starting = true;
  |          
  |       controlChannel.connect(groupName + CONTROL_SUFFIX);
  |       
  |       if (!((JChannel)controlChannel).flushSupported())
  |       {
  |          throw new IllegalStateException("Flush is not supported on the UDP Channel, please check your JGroups UDP stack as Flush is required");
  |       }
  |       
  |       //The first thing that happens after connect is a view change arrives
  |       //Then the state will arrive (if we are not the first member)
  |       //Then the control messages will start arriving.
  |       //We can guarantee that messages won't arrive until after the state is set because we use 
  |       //the FLUSH protocol on the control channel
  |           
  |       boolean first =  !(controlChannel.getState(null, stateTimeout));
  | 


So, the semantic we expect is FLUSH aways returning the state from the cluster, right after the connect. Now something on the change presented at the first post on this thread changed this semantic causing the exception somehow.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4187727#4187727

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4187727