[
https://issues.jboss.org/browse/JGRP-1252?page=com.atlassian.jira.plugin....
]
Bela Ban commented on JGRP-1252:
--------------------------------
Step #7 is optional; it is the equivalent of checkMembers() in your test. It just makes
sure that the cluster has re-formed correctly after the restart of GR and the client.
Again, I restarted GR and the client at least 10 times (with tcpchat.xml), and *never* ran
into an issue.
Note that - in your test - you wait for some time (20s) for the cluster to reform after
the restart. However, MERGE2 is configured to merge between 10 and 30 seconds, so the
merge may not yet have happened when you call checkMembers() in runTest().
Also, I ran this test on 2.12, maybe this is the difference...
TCP Gossip Discovery Issue
--------------------------
Key: JGRP-1252
URL:
https://issues.jboss.org/browse/JGRP-1252
Project: JGroups
Issue Type: Bug
Affects Versions: 2.11
Environment: Windows XP and Solaris 5.10
Reporter: Grahame Rogers
Assignee: Vladimir Blagojevic
Labels: new_and_noteworthy
Fix For: 2.12
Attachments: JGroupsTest.zip, JGroupsTest.zip, JGroupsTest.zip, JGroupsTest.zip,
JGRP-1252-output.txt, JGRP-1252-output2.txt
I run the chat demo app that was shipped with an older version of Jgroups. Using tcp
transport, with tcpgossip for discovery I start up 2 instances of the chat application. I
then restart the gossip server and also another instance of the chat application. The 3rd
instance of the chat application receives a view update (membershipListener.viewAccepted)
only the logical name of one of the 2 previous instances of the chat client is incorrect.
I have detailed the results in:
http://old.nabble.com/TCPGossip-Discovery-Issue-td30227966.html
I will attach the test client to this bug report.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira