12:09 p.m.
merge_view does not correctly update logical_addr_cache
-------------------------------------------------------
Key: JGRP-1073
URL: https://jira.jboss.org/jira/browse/JGRP-1073
Project: JGroups
Issue Type: Bug
Affects Versions: 2.8
Reporter: Nomane Nomane
Assignee: Bela Ban
Attachments: jgroup.log
I have a setup where there is a TCP jgroup cluster with member A&B and in a very short
period of time member A is replaced by member C.
A=10.62.2.68:7800(ACORES) B=10.62.3.108:7800(OULALI) and C=10.62.2.65:7800(jerome)
There is a problem on C where the logical_addr_cache is not updated correctly and the
member A is still in the list of address. Therefore, whenever I try to send a message the
tcp stack try to contact A even if it is down.
analysis:
I use TCPPING to make TCP discovery.
When C starts-up, it contacts member B and retrieves cluster members list :
2009-10-15 17:53:36,489 - received GET_MBRS_RSP from OULALI-79:
own_addr=ACORES-23748, view id=[OULALI-79|8], is_server=true, is_coord=false,
logical_name=ACORES-23748, physical_addrs=10.62.2.68:7800
2009-10-15 17:53:36,489 - message is [dst: jerome-57964, src: OULALI-79 (2 headers),
size=0 bytes, flags=OOB], headers are TCPPING: [PING:
type=GET_MBRS_RSP, arg=own_addr=f5bca2fa-95d5-0791-e4c4-5628f9288962, view
id=[OULALI-79|8], is_server=true, is_coord=false,
logical_name=ACORES-33477, physical_addrs=10.62.2.68:7800], TCP:
[channel_name=RelayDevCluster]
Hereafter member A gets discarded and view is updated by B to C :
2009-10-15 17:53:40,689 - new_view=[OULALI-79|9] [OULALI-79,
jerome-57964]
2009-10-15 17:53:40,689 - jerome-57964: view is [OULALI-79|9] [OULALI-79, jerome-57964]
2009-10-15 17:53:40,689 - VIEW_CHANGE received: [OULALI-79, jerome-57964]
But member A is still contacted whenever I try to send a message:
2009-10-15 17:53:45,733 - failure sending message to 10.62.2.68:7800
java.lang.Exception: connection to 10.62.2.68:7800 could not be established
I attach logs and configuration file of the C node.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12:09 p.m.
New subject: [JBoss JIRA] Updated: (JGRP-1073) merge_view does not correctly update logical_addr_cache
[
https://jira.jboss.org/jira/browse/JGRP-1073?page=com.atlassian.jira.plug...
]
Nomane Nomane updated JGRP-1073:
--------------------------------
Attachment: jgroup.log
merge_view does not correctly update logical_addr_cache
-------------------------------------------------------
Key: JGRP-1073
URL: https://jira.jboss.org/jira/browse/JGRP-1073
Project: JGroups
Issue Type: Bug
Affects Versions: 2.8
Reporter: Nomane Nomane
Assignee: Bela Ban
Attachments: jgroup.log
I have a setup where there is a TCP jgroup cluster with member A&B and in a very
short period of time member A is replaced by member C.
A=10.62.2.68:7800(ACORES) B=10.62.3.108:7800(OULALI) and C=10.62.2.65:7800(jerome)
There is a problem on C where the logical_addr_cache is not updated correctly and the
member A is still in the list of address. Therefore, whenever I try to send a message the
tcp stack try to contact A even if it is down.
analysis:
I use TCPPING to make TCP discovery.
When C starts-up, it contacts member B and retrieves cluster members list :
>2009-10-15 17:53:36,489 - received GET_MBRS_RSP from OULALI-79:
own_addr=ACORES-23748, view id=[OULALI-79|8], is_server=true, is_coord=false,
>logical_name=ACORES-23748, physical_addrs=10.62.2.68:7800
>2009-10-15 17:53:36,489 - message is [dst: jerome-57964, src: OULALI-79 (2 headers),
size=0 bytes, flags=OOB], headers are TCPPING: [PING:
>type=GET_MBRS_RSP, arg=own_addr=f5bca2fa-95d5-0791-e4c4-5628f9288962, view
id=[OULALI-79|8], is_server=true, is_coord=false,
>logical_name=ACORES-33477, physical_addrs=10.62.2.68:7800], TCP:
[channel_name=RelayDevCluster]
Hereafter member A gets discarded and view is updated by B to C :
>2009-10-15 17:53:40,689 - new_view=[OULALI-79|9] [OULALI-79, jerome-57964]
>2009-10-15 17:53:40,689 - jerome-57964: view is [OULALI-79|9] [OULALI-79,
jerome-57964]
>2009-10-15 17:53:40,689 - VIEW_CHANGE received: [OULALI-79, jerome-57964]
But member A is still contacted whenever I try to send a message:
>2009-10-15 17:53:45,733 - failure sending message to 10.62.2.68:7800
>java.lang.Exception: connection to 10.62.2.68:7800 could not be established
I attach logs and configuration file of the C node.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12:11 p.m.
New subject: [JBoss JIRA] Updated: (JGRP-1073) merge_view does not correctly update logical_addr_cache
[
https://jira.jboss.org/jira/browse/JGRP-1073?page=com.atlassian.jira.plug...
]
Nomane Nomane updated JGRP-1073:
--------------------------------
Attachment: tcp.xml
merge_view does not correctly update logical_addr_cache
-------------------------------------------------------
Key: JGRP-1073
URL: https://jira.jboss.org/jira/browse/JGRP-1073
Project: JGroups
Issue Type: Bug
Affects Versions: 2.8
Reporter: Nomane Nomane
Assignee: Bela Ban
Attachments: jgroup.log, tcp.xml
I have a setup where there is a TCP jgroup cluster with member A&B and in a very
short period of time member A is replaced by member C.
A=10.62.2.68:7800(ACORES) B=10.62.3.108:7800(OULALI) and C=10.62.2.65:7800(jerome)
There is a problem on C where the logical_addr_cache is not updated correctly and the
member A is still in the list of address. Therefore, whenever I try to send a message the
tcp stack try to contact A even if it is down.
analysis:
I use TCPPING to make TCP discovery.
When C starts-up, it contacts member B and retrieves cluster members list :
>2009-10-15 17:53:36,489 - received GET_MBRS_RSP from OULALI-79:
own_addr=ACORES-23748, view id=[OULALI-79|8], is_server=true, is_coord=false,
>logical_name=ACORES-23748, physical_addrs=10.62.2.68:7800
>2009-10-15 17:53:36,489 - message is [dst: jerome-57964, src: OULALI-79 (2 headers),
size=0 bytes, flags=OOB], headers are TCPPING: [PING:
>type=GET_MBRS_RSP, arg=own_addr=f5bca2fa-95d5-0791-e4c4-5628f9288962, view
id=[OULALI-79|8], is_server=true, is_coord=false,
>logical_name=ACORES-33477, physical_addrs=10.62.2.68:7800], TCP:
[channel_name=RelayDevCluster]
Hereafter member A gets discarded and view is updated by B to C :
>2009-10-15 17:53:40,689 - new_view=[OULALI-79|9] [OULALI-79, jerome-57964]
>2009-10-15 17:53:40,689 - jerome-57964: view is [OULALI-79|9] [OULALI-79,
jerome-57964]
>2009-10-15 17:53:40,689 - VIEW_CHANGE received: [OULALI-79, jerome-57964]
But member A is still contacted whenever I try to send a message:
>2009-10-15 17:53:45,733 - failure sending message to 10.62.2.68:7800
>java.lang.Exception: connection to 10.62.2.68:7800 could not be established
I attach logs and configuration file of the C node.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12:15 p.m.
New subject: [JBoss JIRA] Commented: (JGRP-1073) merge_view does not correctly update logical_addr_cache
[
https://jira.jboss.org/jira/browse/JGRP-1073?page=com.atlassian.jira.plug...
]
Nomane Nomane commented on JGRP-1073:
-------------------------------------
Note that in the logs there are 2 clusters, InSituDevClusterAndres (that is a udp cluster
and does not exibit any problems) and RelayDevCluster (tcp cluster which does).
merge_view does not correctly update logical_addr_cache
-------------------------------------------------------
Key: JGRP-1073
URL: https://jira.jboss.org/jira/browse/JGRP-1073
Project: JGroups
Issue Type: Bug
Affects Versions: 2.8
Reporter: Nomane Nomane
Assignee: Bela Ban
Attachments: jgroup.log, tcp.xml
I have a setup where there is a TCP jgroup cluster with member A&B and in a very
short period of time member A is replaced by member C.
A=10.62.2.68:7800(ACORES) B=10.62.3.108:7800(OULALI) and C=10.62.2.65:7800(jerome)
There is a problem on C where the logical_addr_cache is not updated correctly and the
member A is still in the list of address. Therefore, whenever I try to send a message the
tcp stack try to contact A even if it is down.
analysis:
I use TCPPING to make TCP discovery.
When C starts-up, it contacts member B and retrieves cluster members list :
>2009-10-15 17:53:36,489 - received GET_MBRS_RSP from OULALI-79:
own_addr=ACORES-23748, view id=[OULALI-79|8], is_server=true, is_coord=false,
>logical_name=ACORES-23748, physical_addrs=10.62.2.68:7800
>2009-10-15 17:53:36,489 - message is [dst: jerome-57964, src: OULALI-79 (2 headers),
size=0 bytes, flags=OOB], headers are TCPPING: [PING:
>type=GET_MBRS_RSP, arg=own_addr=f5bca2fa-95d5-0791-e4c4-5628f9288962, view
id=[OULALI-79|8], is_server=true, is_coord=false,
>logical_name=ACORES-33477, physical_addrs=10.62.2.68:7800], TCP:
[channel_name=RelayDevCluster]
Hereafter member A gets discarded and view is updated by B to C :
>2009-10-15 17:53:40,689 - new_view=[OULALI-79|9] [OULALI-79, jerome-57964]
>2009-10-15 17:53:40,689 - jerome-57964: view is [OULALI-79|9] [OULALI-79,
jerome-57964]
>2009-10-15 17:53:40,689 - VIEW_CHANGE received: [OULALI-79, jerome-57964]
But member A is still contacted whenever I try to send a message:
>2009-10-15 17:53:45,733 - failure sending message to 10.62.2.68:7800
>java.lang.Exception: connection to 10.62.2.68:7800 could not be established
I attach logs and configuration file of the C node.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
2:50 p.m.
New subject: [JBoss JIRA] Updated: (JGRP-1073) merge_view does not correctly update logical_addr_cache
[
https://jira.jboss.org/jira/browse/JGRP-1073?page=com.atlassian.jira.plug...
]
Bela Ban updated JGRP-1073:
---------------------------
Fix Version/s: 2.8
merge_view does not correctly update logical_addr_cache
-------------------------------------------------------
Key: JGRP-1073
URL: https://jira.jboss.org/jira/browse/JGRP-1073
Project: JGroups
Issue Type: Bug
Affects Versions: 2.8
Reporter: Nomane Nomane
Assignee: Bela Ban
Fix For: 2.8
Attachments: jgroup.log, tcp.xml
I have a setup where there is a TCP jgroup cluster with member A&B and in a very
short period of time member A is replaced by member C.
A=10.62.2.68:7800(ACORES) B=10.62.3.108:7800(OULALI) and C=10.62.2.65:7800(jerome)
There is a problem on C where the logical_addr_cache is not updated correctly and the
member A is still in the list of address. Therefore, whenever I try to send a message the
tcp stack try to contact A even if it is down.
analysis:
I use TCPPING to make TCP discovery.
When C starts-up, it contacts member B and retrieves cluster members list :
>2009-10-15 17:53:36,489 - received GET_MBRS_RSP from OULALI-79:
own_addr=ACORES-23748, view id=[OULALI-79|8], is_server=true, is_coord=false,
>logical_name=ACORES-23748, physical_addrs=10.62.2.68:7800
>2009-10-15 17:53:36,489 - message is [dst: jerome-57964, src: OULALI-79 (2 headers),
size=0 bytes, flags=OOB], headers are TCPPING: [PING:
>type=GET_MBRS_RSP, arg=own_addr=f5bca2fa-95d5-0791-e4c4-5628f9288962, view
id=[OULALI-79|8], is_server=true, is_coord=false,
>logical_name=ACORES-33477, physical_addrs=10.62.2.68:7800], TCP:
[channel_name=RelayDevCluster]
Hereafter member A gets discarded and view is updated by B to C :
>2009-10-15 17:53:40,689 - new_view=[OULALI-79|9] [OULALI-79, jerome-57964]
>2009-10-15 17:53:40,689 - jerome-57964: view is [OULALI-79|9] [OULALI-79,
jerome-57964]
>2009-10-15 17:53:40,689 - VIEW_CHANGE received: [OULALI-79, jerome-57964]
But member A is still contacted whenever I try to send a message:
>2009-10-15 17:53:45,733 - failure sending message to 10.62.2.68:7800
>java.lang.Exception: connection to 10.62.2.68:7800 could not be established
I attach logs and configuration file of the C node.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
2:33 a.m.
New subject: [JBoss JIRA] Commented: (JGRP-1073) merge_view does not correctly update logical_addr_cache
[
https://jira.jboss.org/jira/browse/JGRP-1073?page=com.atlassian.jira.plug...
]
Bela Ban commented on JGRP-1073:
--------------------------------
The issue is caused by the new view *lazily* removing A from the logical address cache. It
will take 120 seconds for A to get removed, but only if there's another add() or
remove(). Since a TCP-based multicast sends the message to *all* elements of the logical
address cache, A will always get contacted.
merge_view does not correctly update logical_addr_cache
-------------------------------------------------------
Key: JGRP-1073
URL: https://jira.jboss.org/jira/browse/JGRP-1073
Project: JGroups
Issue Type: Bug
Affects Versions: 2.8
Reporter: Nomane Nomane
Assignee: Bela Ban
Fix For: 2.8
Attachments: jgroup.log, tcp.xml
I have a setup where there is a TCP jgroup cluster with member A&B and in a very
short period of time member A is replaced by member C.
A=10.62.2.68:7800(ACORES) B=10.62.3.108:7800(OULALI) and C=10.62.2.65:7800(jerome)
There is a problem on C where the logical_addr_cache is not updated correctly and the
member A is still in the list of address. Therefore, whenever I try to send a message the
tcp stack try to contact A even if it is down.
analysis:
I use TCPPING to make TCP discovery.
When C starts-up, it contacts member B and retrieves cluster members list :
>2009-10-15 17:53:36,489 - received GET_MBRS_RSP from OULALI-79:
own_addr=ACORES-23748, view id=[OULALI-79|8], is_server=true, is_coord=false,
>logical_name=ACORES-23748, physical_addrs=10.62.2.68:7800
>2009-10-15 17:53:36,489 - message is [dst: jerome-57964, src: OULALI-79 (2 headers),
size=0 bytes, flags=OOB], headers are TCPPING: [PING:
>type=GET_MBRS_RSP, arg=own_addr=f5bca2fa-95d5-0791-e4c4-5628f9288962, view
id=[OULALI-79|8], is_server=true, is_coord=false,
>logical_name=ACORES-33477, physical_addrs=10.62.2.68:7800], TCP:
[channel_name=RelayDevCluster]
Hereafter member A gets discarded and view is updated by B to C :
>2009-10-15 17:53:40,689 - new_view=[OULALI-79|9] [OULALI-79, jerome-57964]
>2009-10-15 17:53:40,689 - jerome-57964: view is [OULALI-79|9] [OULALI-79,
jerome-57964]
>2009-10-15 17:53:40,689 - VIEW_CHANGE received: [OULALI-79, jerome-57964]
But member A is still contacted whenever I try to send a message:
>2009-10-15 17:53:45,733 - failure sending message to 10.62.2.68:7800
>java.lang.Exception: connection to 10.62.2.68:7800 could not be established
I attach logs and configuration file of the C node.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
2:40 a.m.
New subject: [JBoss JIRA] Commented: (JGRP-1073) merge_view does not correctly update logical_addr_cache
[
https://jira.jboss.org/jira/browse/JGRP-1073?page=com.atlassian.jira.plug...
]
Bela Ban commented on JGRP-1073:
--------------------------------
Nope, can't do this due to https://jira.jboss.org/jira/browse/JGRP-918
merge_view does not correctly update logical_addr_cache
-------------------------------------------------------
Key: JGRP-1073
URL: https://jira.jboss.org/jira/browse/JGRP-1073
Project: JGroups
Issue Type: Bug
Affects Versions: 2.8
Reporter: Nomane Nomane
Assignee: Bela Ban
Fix For: 2.8
Attachments: jgroup.log, tcp.xml
I have a setup where there is a TCP jgroup cluster with member A&B and in a very
short period of time member A is replaced by member C.
A=10.62.2.68:7800(ACORES) B=10.62.3.108:7800(OULALI) and C=10.62.2.65:7800(jerome)
There is a problem on C where the logical_addr_cache is not updated correctly and the
member A is still in the list of address. Therefore, whenever I try to send a message the
tcp stack try to contact A even if it is down.
analysis:
I use TCPPING to make TCP discovery.
When C starts-up, it contacts member B and retrieves cluster members list :
>2009-10-15 17:53:36,489 - received GET_MBRS_RSP from OULALI-79:
own_addr=ACORES-23748, view id=[OULALI-79|8], is_server=true, is_coord=false,
>logical_name=ACORES-23748, physical_addrs=10.62.2.68:7800
>2009-10-15 17:53:36,489 - message is [dst: jerome-57964, src: OULALI-79 (2 headers),
size=0 bytes, flags=OOB], headers are TCPPING: [PING:
>type=GET_MBRS_RSP, arg=own_addr=f5bca2fa-95d5-0791-e4c4-5628f9288962, view
id=[OULALI-79|8], is_server=true, is_coord=false,
>logical_name=ACORES-33477, physical_addrs=10.62.2.68:7800], TCP:
[channel_name=RelayDevCluster]
Hereafter member A gets discarded and view is updated by B to C :
>2009-10-15 17:53:40,689 - new_view=[OULALI-79|9] [OULALI-79, jerome-57964]
>2009-10-15 17:53:40,689 - jerome-57964: view is [OULALI-79|9] [OULALI-79,
jerome-57964]
>2009-10-15 17:53:40,689 - VIEW_CHANGE received: [OULALI-79, jerome-57964]
But member A is still contacted whenever I try to send a message:
>2009-10-15 17:53:45,733 - failure sending message to 10.62.2.68:7800
>java.lang.Exception: connection to 10.62.2.68:7800 could not be established
I attach logs and configuration file of the C node.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
3:52 a.m.
New subject: [JBoss JIRA] Commented: (JGRP-1073) merge_view does not correctly update logical_addr_cache
[
https://jira.jboss.org/jira/browse/JGRP-1073?page=com.atlassian.jira.plug...
]
Nomane Nomane commented on JGRP-1073:
-------------------------------------
Thank you Bela for your reply,
What do you mean by "Nope, can't do this due to
https://jira.jboss.org/jira/browse/JGRP-918";, you will keep this behavior whatever
the fact that logical address cache is wrong ?
merge_view does not correctly update logical_addr_cache
-------------------------------------------------------
Key: JGRP-1073
URL: https://jira.jboss.org/jira/browse/JGRP-1073
Project: JGroups
Issue Type: Bug
Affects Versions: 2.8
Reporter: Nomane Nomane
Assignee: Bela Ban
Fix For: 2.8
Attachments: jgroup.log, tcp.xml
I have a setup where there is a TCP jgroup cluster with member A&B and in a very
short period of time member A is replaced by member C.
A=10.62.2.68:7800(ACORES) B=10.62.3.108:7800(OULALI) and C=10.62.2.65:7800(jerome)
There is a problem on C where the logical_addr_cache is not updated correctly and the
member A is still in the list of address. Therefore, whenever I try to send a message the
tcp stack try to contact A even if it is down.
analysis:
I use TCPPING to make TCP discovery.
When C starts-up, it contacts member B and retrieves cluster members list :
>2009-10-15 17:53:36,489 - received GET_MBRS_RSP from OULALI-79:
own_addr=ACORES-23748, view id=[OULALI-79|8], is_server=true, is_coord=false,
>logical_name=ACORES-23748, physical_addrs=10.62.2.68:7800
>2009-10-15 17:53:36,489 - message is [dst: jerome-57964, src: OULALI-79 (2 headers),
size=0 bytes, flags=OOB], headers are TCPPING: [PING:
>type=GET_MBRS_RSP, arg=own_addr=f5bca2fa-95d5-0791-e4c4-5628f9288962, view
id=[OULALI-79|8], is_server=true, is_coord=false,
>logical_name=ACORES-33477, physical_addrs=10.62.2.68:7800], TCP:
[channel_name=RelayDevCluster]
Hereafter member A gets discarded and view is updated by B to C :
>2009-10-15 17:53:40,689 - new_view=[OULALI-79|9] [OULALI-79, jerome-57964]
>2009-10-15 17:53:40,689 - jerome-57964: view is [OULALI-79|9] [OULALI-79,
jerome-57964]
>2009-10-15 17:53:40,689 - VIEW_CHANGE received: [OULALI-79, jerome-57964]
But member A is still contacted whenever I try to send a message:
>2009-10-15 17:53:45,733 - failure sending message to 10.62.2.68:7800
>java.lang.Exception: connection to 10.62.2.68:7800 could not be established
I attach logs and configuration file of the C node.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:07 a.m.
New subject: [JBoss JIRA] Commented: (JGRP-1073) merge_view does not correctly update logical_addr_cache
[
https://jira.jboss.org/jira/browse/JGRP-1073?page=com.atlassian.jira.plug...
]
Bela Ban commented on JGRP-1073:
--------------------------------
No, but we cannot remove the non-members of a given view from the logical address cache.
However, here's what I did to solve this (in BasicTCP):
- When sending a message and skip_suspected_mbrs is true, if there's an exception, we
add the destination to the suspected_mbrs list
- When sending a message, and the dest is part of suspected_mbrs, we drop the message
- When receiving traffic from that member (e.g. through a new TCP connection), we remove
the member from suspected_mbrs
The test suite passes with these changes
merge_view does not correctly update logical_addr_cache
-------------------------------------------------------
Key: JGRP-1073
URL: https://jira.jboss.org/jira/browse/JGRP-1073
Project: JGroups
Issue Type: Bug
Affects Versions: 2.8
Reporter: Nomane Nomane
Assignee: Bela Ban
Fix For: 2.8
Attachments: jgroup.log, tcp.xml
I have a setup where there is a TCP jgroup cluster with member A&B and in a very
short period of time member A is replaced by member C.
A=10.62.2.68:7800(ACORES) B=10.62.3.108:7800(OULALI) and C=10.62.2.65:7800(jerome)
There is a problem on C where the logical_addr_cache is not updated correctly and the
member A is still in the list of address. Therefore, whenever I try to send a message the
tcp stack try to contact A even if it is down.
analysis:
I use TCPPING to make TCP discovery.
When C starts-up, it contacts member B and retrieves cluster members list :
>2009-10-15 17:53:36,489 - received GET_MBRS_RSP from OULALI-79:
own_addr=ACORES-23748, view id=[OULALI-79|8], is_server=true, is_coord=false,
>logical_name=ACORES-23748, physical_addrs=10.62.2.68:7800
>2009-10-15 17:53:36,489 - message is [dst: jerome-57964, src: OULALI-79 (2 headers),
size=0 bytes, flags=OOB], headers are TCPPING: [PING:
>type=GET_MBRS_RSP, arg=own_addr=f5bca2fa-95d5-0791-e4c4-5628f9288962, view
id=[OULALI-79|8], is_server=true, is_coord=false,
>logical_name=ACORES-33477, physical_addrs=10.62.2.68:7800], TCP:
[channel_name=RelayDevCluster]
Hereafter member A gets discarded and view is updated by B to C :
>2009-10-15 17:53:40,689 - new_view=[OULALI-79|9] [OULALI-79, jerome-57964]
>2009-10-15 17:53:40,689 - jerome-57964: view is [OULALI-79|9] [OULALI-79,
jerome-57964]
>2009-10-15 17:53:40,689 - VIEW_CHANGE received: [OULALI-79, jerome-57964]
But member A is still contacted whenever I try to send a message:
>2009-10-15 17:53:45,733 - failure sending message to 10.62.2.68:7800
>java.lang.Exception: connection to 10.62.2.68:7800 could not be established
I attach logs and configuration file of the C node.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:16 a.m.
New subject: [JBoss JIRA] Resolved: (JGRP-1073) merge_view does not correctly update logical_addr_cache
[
https://jira.jboss.org/jira/browse/JGRP-1073?page=com.atlassian.jira.plug...
]
Bela Ban resolved JGRP-1073.
----------------------------
Resolution: Done
merge_view does not correctly update logical_addr_cache
-------------------------------------------------------
Key: JGRP-1073
URL: https://jira.jboss.org/jira/browse/JGRP-1073
Project: JGroups
Issue Type: Bug
Affects Versions: 2.8
Reporter: Nomane Nomane
Assignee: Bela Ban
Fix For: 2.8
Attachments: jgroup.log, tcp.xml
I have a setup where there is a TCP jgroup cluster with member A&B and in a very
short period of time member A is replaced by member C.
A=10.62.2.68:7800(ACORES) B=10.62.3.108:7800(OULALI) and C=10.62.2.65:7800(jerome)
There is a problem on C where the logical_addr_cache is not updated correctly and the
member A is still in the list of address. Therefore, whenever I try to send a message the
tcp stack try to contact A even if it is down.
analysis:
I use TCPPING to make TCP discovery.
When C starts-up, it contacts member B and retrieves cluster members list :
>2009-10-15 17:53:36,489 - received GET_MBRS_RSP from OULALI-79:
own_addr=ACORES-23748, view id=[OULALI-79|8], is_server=true, is_coord=false,
>logical_name=ACORES-23748, physical_addrs=10.62.2.68:7800
>2009-10-15 17:53:36,489 - message is [dst: jerome-57964, src: OULALI-79 (2 headers),
size=0 bytes, flags=OOB], headers are TCPPING: [PING:
>type=GET_MBRS_RSP, arg=own_addr=f5bca2fa-95d5-0791-e4c4-5628f9288962, view
id=[OULALI-79|8], is_server=true, is_coord=false,
>logical_name=ACORES-33477, physical_addrs=10.62.2.68:7800], TCP:
[channel_name=RelayDevCluster]
Hereafter member A gets discarded and view is updated by B to C :
>2009-10-15 17:53:40,689 - new_view=[OULALI-79|9] [OULALI-79, jerome-57964]
>2009-10-15 17:53:40,689 - jerome-57964: view is [OULALI-79|9] [OULALI-79,
jerome-57964]
>2009-10-15 17:53:40,689 - VIEW_CHANGE received: [OULALI-79, jerome-57964]
But member A is still contacted whenever I try to send a message:
>2009-10-15 17:53:45,733 - failure sending message to 10.62.2.68:7800
>java.lang.Exception: connection to 10.62.2.68:7800 could not be established
I attach logs and configuration file of the C node.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:24 a.m.
New subject: [JBoss JIRA] Commented: (JGRP-1073) merge_view does not correctly update logical_addr_cache
[
https://jira.jboss.org/jira/browse/JGRP-1073?page=com.atlassian.jira.plug...
]
Nomane Nomane commented on JGRP-1073:
-------------------------------------
I have checked in BasicTCP class (function sendUnicast) , you manage suspect member by
avoiding to send them a message by handle exception and a suspect list,
but concerning the cache, you know that despite the fact suspect list contain elements, we
continue (in this ticket use case) to try to connect to member A (until the end of the
program),
you said that "It will take 120 seconds for A to get removed, but only if there's
another add() or remove()", you mean that the deprecated member in cache will be
remove only if a new view will be send ?
merge_view does not correctly update logical_addr_cache
-------------------------------------------------------
Key: JGRP-1073
URL: https://jira.jboss.org/jira/browse/JGRP-1073
Project: JGroups
Issue Type: Bug
Affects Versions: 2.8
Reporter: Nomane Nomane
Assignee: Bela Ban
Fix For: 2.8
Attachments: jgroup.log, tcp.xml
I have a setup where there is a TCP jgroup cluster with member A&B and in a very
short period of time member A is replaced by member C.
A=10.62.2.68:7800(ACORES) B=10.62.3.108:7800(OULALI) and C=10.62.2.65:7800(jerome)
There is a problem on C where the logical_addr_cache is not updated correctly and the
member A is still in the list of address. Therefore, whenever I try to send a message the
tcp stack try to contact A even if it is down.
analysis:
I use TCPPING to make TCP discovery.
When C starts-up, it contacts member B and retrieves cluster members list :
>2009-10-15 17:53:36,489 - received GET_MBRS_RSP from OULALI-79:
own_addr=ACORES-23748, view id=[OULALI-79|8], is_server=true, is_coord=false,
>logical_name=ACORES-23748, physical_addrs=10.62.2.68:7800
>2009-10-15 17:53:36,489 - message is [dst: jerome-57964, src: OULALI-79 (2 headers),
size=0 bytes, flags=OOB], headers are TCPPING: [PING:
>type=GET_MBRS_RSP, arg=own_addr=f5bca2fa-95d5-0791-e4c4-5628f9288962, view
id=[OULALI-79|8], is_server=true, is_coord=false,
>logical_name=ACORES-33477, physical_addrs=10.62.2.68:7800], TCP:
[channel_name=RelayDevCluster]
Hereafter member A gets discarded and view is updated by B to C :
>2009-10-15 17:53:40,689 - new_view=[OULALI-79|9] [OULALI-79, jerome-57964]
>2009-10-15 17:53:40,689 - jerome-57964: view is [OULALI-79|9] [OULALI-79,
jerome-57964]
>2009-10-15 17:53:40,689 - VIEW_CHANGE received: [OULALI-79, jerome-57964]
But member A is still contacted whenever I try to send a message:
>2009-10-15 17:53:45,733 - failure sending message to 10.62.2.68:7800
>java.lang.Exception: connection to 10.62.2.68:7800 could not be established
I attach logs and configuration file of the C node.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:41 a.m.
New subject: [JBoss JIRA] Commented: (JGRP-1073) merge_view does not correctly update logical_addr_cache
[
https://jira.jboss.org/jira/browse/JGRP-1073?page=com.atlassian.jira.plug...
]
Bela Ban commented on JGRP-1073:
--------------------------------
OK, I added some code to BasicTCP.sendUnicast() where a failed destination is removed from
the logical address cache. I'll commit as soon as the testsuite passed
merge_view does not correctly update logical_addr_cache
-------------------------------------------------------
Key: JGRP-1073
URL: https://jira.jboss.org/jira/browse/JGRP-1073
Project: JGroups
Issue Type: Bug
Affects Versions: 2.8
Reporter: Nomane Nomane
Assignee: Bela Ban
Fix For: 2.8
Attachments: jgroup.log, tcp.xml
I have a setup where there is a TCP jgroup cluster with member A&B and in a very
short period of time member A is replaced by member C.
A=10.62.2.68:7800(ACORES) B=10.62.3.108:7800(OULALI) and C=10.62.2.65:7800(jerome)
There is a problem on C where the logical_addr_cache is not updated correctly and the
member A is still in the list of address. Therefore, whenever I try to send a message the
tcp stack try to contact A even if it is down.
analysis:
I use TCPPING to make TCP discovery.
When C starts-up, it contacts member B and retrieves cluster members list :
>2009-10-15 17:53:36,489 - received GET_MBRS_RSP from OULALI-79:
own_addr=ACORES-23748, view id=[OULALI-79|8], is_server=true, is_coord=false,
>logical_name=ACORES-23748, physical_addrs=10.62.2.68:7800
>2009-10-15 17:53:36,489 - message is [dst: jerome-57964, src: OULALI-79 (2 headers),
size=0 bytes, flags=OOB], headers are TCPPING: [PING:
>type=GET_MBRS_RSP, arg=own_addr=f5bca2fa-95d5-0791-e4c4-5628f9288962, view
id=[OULALI-79|8], is_server=true, is_coord=false,
>logical_name=ACORES-33477, physical_addrs=10.62.2.68:7800], TCP:
[channel_name=RelayDevCluster]
Hereafter member A gets discarded and view is updated by B to C :
>2009-10-15 17:53:40,689 - new_view=[OULALI-79|9] [OULALI-79, jerome-57964]
>2009-10-15 17:53:40,689 - jerome-57964: view is [OULALI-79|9] [OULALI-79,
jerome-57964]
>2009-10-15 17:53:40,689 - VIEW_CHANGE received: [OULALI-79, jerome-57964]
But member A is still contacted whenever I try to send a message:
>2009-10-15 17:53:45,733 - failure sending message to 10.62.2.68:7800
>java.lang.Exception: connection to 10.62.2.68:7800 could not be established
I attach logs and configuration file of the C node.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:45 a.m.
New subject: [JBoss JIRA] Commented: (JGRP-1073) merge_view does not correctly update logical_addr_cache
[
https://jira.jboss.org/jira/browse/JGRP-1073?page=com.atlassian.jira.plug...
]
Nomane Nomane commented on JGRP-1073:
-------------------------------------
Thanks you!
merge_view does not correctly update logical_addr_cache
-------------------------------------------------------
Key: JGRP-1073
URL: https://jira.jboss.org/jira/browse/JGRP-1073
Project: JGroups
Issue Type: Bug
Affects Versions: 2.8
Reporter: Nomane Nomane
Assignee: Bela Ban
Fix For: 2.8
Attachments: jgroup.log, tcp.xml
I have a setup where there is a TCP jgroup cluster with member A&B and in a very
short period of time member A is replaced by member C.
A=10.62.2.68:7800(ACORES) B=10.62.3.108:7800(OULALI) and C=10.62.2.65:7800(jerome)
There is a problem on C where the logical_addr_cache is not updated correctly and the
member A is still in the list of address. Therefore, whenever I try to send a message the
tcp stack try to contact A even if it is down.
analysis:
I use TCPPING to make TCP discovery.
When C starts-up, it contacts member B and retrieves cluster members list :
>2009-10-15 17:53:36,489 - received GET_MBRS_RSP from OULALI-79:
own_addr=ACORES-23748, view id=[OULALI-79|8], is_server=true, is_coord=false,
>logical_name=ACORES-23748, physical_addrs=10.62.2.68:7800
>2009-10-15 17:53:36,489 - message is [dst: jerome-57964, src: OULALI-79 (2 headers),
size=0 bytes, flags=OOB], headers are TCPPING: [PING:
>type=GET_MBRS_RSP, arg=own_addr=f5bca2fa-95d5-0791-e4c4-5628f9288962, view
id=[OULALI-79|8], is_server=true, is_coord=false,
>logical_name=ACORES-33477, physical_addrs=10.62.2.68:7800], TCP:
[channel_name=RelayDevCluster]
Hereafter member A gets discarded and view is updated by B to C :
>2009-10-15 17:53:40,689 - new_view=[OULALI-79|9] [OULALI-79, jerome-57964]
>2009-10-15 17:53:40,689 - jerome-57964: view is [OULALI-79|9] [OULALI-79,
jerome-57964]
>2009-10-15 17:53:40,689 - VIEW_CHANGE received: [OULALI-79, jerome-57964]
But member A is still contacted whenever I try to send a message:
>2009-10-15 17:53:45,733 - failure sending message to 10.62.2.68:7800
>java.lang.Exception: connection to 10.62.2.68:7800 could not be established
I attach logs and configuration file of the C node.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
6038
days inactive
6063
days old
12 comments
2 participants
participants (2)
-
Bela Ban (JIRA) -
Nomane Nomane (JIRA)