[
https://issues.jboss.org/browse/JGRP-1252?page=com.atlassian.jira.plugin....
]
Grahame Rogers commented on JGRP-1252:
--------------------------------------
Hi, I'm not sure what you mean "by the next discovery phase". Do you mean
that if I wait long enough, the problem will resolve itself on the next sweep which occurs
automatically? If so, I have waited minutes and the situation has not corrected itself -
is there possible something wrong with the way I am configured? Example of my config is in
the test projects I have uploaded here. If you mean, the next time a new node connects to
GossipRouter then this will resolve itself, then this is correct, but I don't want to
be waiting around for this scenario to occur as it could be a long period of time, or even
never.
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.11.1, 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