JBM clustering: jboss.messaging.groupname ignored?
What i want to do:
I'm using JBM 1.4.2.GA-SP1 in JBoss 4.2.3.GA, in a clustered configuration. I want to have 2 clusters on the same local network (with automatic discovery), so i thought of using the -g launch argument or its JBM equivalent (which seems to be -Djboss.messaging.groupname)
Here is my problem:
While the general JBoss clustering mechanism of using different -g values to specify different Partitions works fine (nodes launched with different -g effectively join separate and isolated partitions, this isn't the case with JBM: all nodes launched on the same local network (where discovery works) always join the same JBM Group, ignoring the different launch argument.
Also there is something i don't understand: do i have to specify BOTH the partition and the group? It seems redundant but maybe i'm missing something.
Here are my launch arguments for both nodes (the intent is to have 2 separate clusters):
NODE 1:
run.sh -c all -g Partition1 -b[IP1] -Djboss.messaging.groupname=Groupe1 -Djboss.messaging.ServerPeerID=1
NODE 2:
run.sh -c all2 -g Partition2 -b[IP2] -Djboss.messaging.groupname=Groupe2 -Djboss.messaging.ServerPeerID=1
-->If i use ServerPeerID=1 for the second node the startup fails, which is consistent since both nodes are considered to be in the same messaging group.
-->If i use ServerPeerID=2 for the second node the startup successes, but then i receive messages from one partition on the other (which is also consistent with the fact that both nodes are considered to be in the same messaging group).
Here are the startup logs i see in this case on the two nodes (Node1 is started completely before Node2 is launched):
[...]
Node1:
//Note: here is the Partition log: 17:45:21,317 INFO [PartitionNavineoCLA_1] Number of cluster members: 1 17:45:21,317 INFO [PartitionNavineoCLA_1] Other members: 0 17:45:21,317 INFO [PartitionNavineoCLA_1] Fetching state (will wait for 30000 milliseconds): 17:45:21,317 INFO [PartitionNavineoCLA_1] State could not be retrieved (we are the first member in group) [...] //Note: here is the JBM log: 17:45:39,757 INFO [GroupMember] org.jboss.messaging.core.impl.postoffice.GroupMember$ControlMembershipListener@89e0c6 got new view [[IP1]:52366|0] [[IP1]:52366], old view is null 17:45:39,757 INFO [GroupMember] I am ([IP1]:52366) 17:45:39,758 INFO [GroupMember] New Members : 1 ([[IP1]:52366]) 17:45:39,758 INFO [GroupMember] All Members : 1 ([[IP1]:52366]) 17:45:39,761 INFO [MPING] sockets will use interface [IP1] 17:45:39,771 INFO [ConnectionTable] server socket created on [IP1]:7900
[...]
Node2:
[...]
//Note: here is the Partition log: (which shows that the partitions are separate) 18:12:43,466 WARN [UDP] discarded message from different group "Tomcat-PartitionNavineoCLA_1" (our group is "Tomcat-PartitionNavineoCLA_2"). Sender was [IP1]:53378 18:12:43,507 WARN [UDP] discarded message from different group "Tomcat-PartitionNavineoCLA_1" (our group is "Tomcat-PartitionNavineoCLA_2"). Sender was [IP1]:53378 18:12:48,945 WARN [UDP] discarded message from different group "PartitionNavineoCLA_1" (our group is "PartitionNavineoCLA_2"). Sender was [IP1]:42374 18:12:49,945 WARN [UDP] discarded message from different group "PartitionNavineoCLA_1" (our group is "PartitionNavineoCLA_2"). Sender was [IP1]:42374 18:13:02,902 INFO [PartitionNavineoCLA_2] Number of cluster members: 1 18:13:02,902 INFO [PartitionNavineoCLA_2] Other members: 0 18:13:02,902 INFO [PartitionNavineoCLA_2] Fetching state (will wait for 30000 milliseconds): 18:13:02,902 INFO [PartitionNavineoCLA_2] State could not be retrieved (we are the first member in group) [...] //Note: here is the JBM log (which shows that the JBM groups are NOT separate): 18:13:16,818 INFO [GroupMember] org.jboss.messaging.core.impl.postoffice.GroupMember$ControlMembershipListener@1e13ce3 got new view [[IP1]:52366|1] [[IP1]:52366, [IP2]:37550], old view is null 18:13:16,818 INFO [GroupMember] I am ([IP2]:37550) 18:13:16,818 INFO [GroupMember] New Members : 2 ([[IP1]:52366, [IP2]:37550]) 18:13:16,818 INFO [GroupMember] All Members : 2 ([[IP1]:52366, [IP2]:37550]) 18:13:17,150 INFO [STATE_TRANSFER] Successful flush at [IP2]:37550 18:13:17,495 INFO [MPING] sockets will use interface [IP2] 18:13:17,529 INFO [ConnectionTable] server socket created on [IP2]:7900 [...]
NB: i also tried a groupname argument with the same value as the -g, but it didn't change anything.
