[
https://issues.jboss.org/browse/JGRP-1252?page=com.atlassian.jira.plugin....
]
Grahame Rogers commented on JGRP-1252:
--------------------------------------
I rarely get a merge in this scenario, just a list containing the right amount of views,
with generally one member with the duff name, for exactly the reason you describe. Not
sure I can really control delaying client 4 logging in. To be honest, I think the scenario
could occur with the existing nodes logging back in after a GR restart, as this is a
timing issue - may be wrong. I think I will try out the programatic solution that you
describe, this sounds like a pragmatic solution to what is just an edge case.
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