[ https://issues.jboss.org/browse/JGRP-1523?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1523: -------------------------------- Can you elaborate a bit more ? The suspected_mbrs field is updated also when there is a view change, as all non-members are removed. Other members need to keep suspected members in their suspected_mbrs list, as they may become coordinator themselves. The 'wasteful' doesn't really bother me, as there won't be many suspected members in a list at any given time, and they're cleared after the new view excluding them is installed. I do care about the 'wrong' part of your statement. Can you elaborate ? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JGRP-1523?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1523: -------------------------------- I still don't understand. What do you mean by [old_suspect, new_suspect, me, ...] ? Can you write down a step-by-step description of the scenario that leads to the incorrect state ? You can also ping me on IRC (#jgroups @ irc.freenode.net) if you want to discuss this interactively, or we can have a phone call. (I do speak German if that's of any help) I'd like to release JGroups 3.2.0.Final by the end of October (actually: 1 week before the end of Oct), so if you want this to be fixed and included, as need to act asap. Cheers, -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JGRP-1523?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1523: -------------------------------- are in the suspect list, but from which we do receive traffic ? [1:25pm] dberindei joined the chat room. [1:26pm] bela: ok, simple solution: [1:26pm] bela: if msg_counts_as_heartbeat is true and we do receive a message from a member in suspected_mbrs, we remove it from suspected_mbrs [1:28pm] jboehm: why not recheck the timestamps in suspect()? [1:28pm] jboehm: should be faster [1:29pm] jboehm: suspect is only called if a new member is suspected, not every message, like update() in this case [1:30pm] bela: So how would you remove A from suspected_mbrs then ? [1:32pm] jboehm: in FD_ALL.suspect() instead of eligible_mbrs.removeAll(suspected_mbrs); iterate over suspected_mebrs, get the time stamp, check if it is OK and remove only if not [1:33pm] jboehm: or something like that [1:34pm] bela: aha. And remove members from suspected_mbrs whose timestamps are below the timeout. Hmm, would work I guess -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JGRP-1523?page=com.atlassian.jira.plugin.... ] Bela Ban edited comment on JGRP-1523 at 10/19/12 2:42 AM: ---------------------------------------------------------- [1:26pm] bela: ok, simple solution: [1:26pm] bela: if msg_counts_as_heartbeat is true and we do receive a message (or a heartbeat) from a member in suspected_mbrs, we remove it from suspected_mbrs [1:28pm] jboehm: why not recheck the timestamps in suspect()? [1:28pm] jboehm: should be faster [1:29pm] jboehm: suspect is only called if a new member is suspected, not every message, like update() in this case [1:30pm] bela: So how would you remove A from suspected_mbrs then ? [1:32pm] jboehm: in FD_ALL.suspect() instead of eligible_mbrs.removeAll(suspected_mbrs); iterate over suspected_mebrs, get the time stamp, check if it is OK and remove only if not [1:33pm] jboehm: or something like that [1:34pm] bela: aha. And remove members from suspected_mbrs whose timestamps are below the timeout. Hmm, would work I guess was (Author: belaban): are in the suspect list, but from which we do receive traffic ? [1:25pm] dberindei joined the chat room. [1:26pm] bela: ok, simple solution: [1:26pm] bela: if msg_counts_as_heartbeat is true and we do receive a message from a member in suspected_mbrs, we remove it from suspected_mbrs [1:28pm] jboehm: why not recheck the timestamps in suspect()? [1:28pm] jboehm: should be faster [1:29pm] jboehm: suspect is only called if a new member is suspected, not every message, like update() in this case [1:30pm] bela: So how would you remove A from suspected_mbrs then ? [1:32pm] jboehm: in FD_ALL.suspect() instead of eligible_mbrs.removeAll(suspected_mbrs); iterate over suspected_mebrs, get the time stamp, check if it is OK and remove only if not [1:33pm] jboehm: or something like that [1:34pm] bela: aha. And remove members from suspected_mbrs whose timestamps are below the timeout. Hmm, would work I guess -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JGRP-1523?page=com.atlassian.jira.plugin.... ] Bela Ban edited comment on JGRP-1523 at 10/19/12 2:48 AM: ---------------------------------------------------------- Actually, the above idea to only check the suspected members on suspect() won't cut it, as an UNSUSPECT event has to be sent up and down the stack, because GMS also keeps a list of suspected members. SOLUTION: - On reception of a message (if msg_counts_as_heartbeat=true) or a heartbeat from P, if P is in suspected_mbrs: remove P from suspected_mbrs and send an UNSUSPECT event up and down the stack - We could maintain a volatile variable has_suspected_mbrs which is set to true when suspected_mbrs is > 0, and false otherwise, so the cost would be minimal was (Author: belaban): We also need to send an UNSUSPECT up and down the stack, as GMS also keeps a list of suspected members. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira