10:54 a.m.
David Hotham created JGRP-1493:
----------------------------------
Summary: Merge fails because failing to get physical address takes too long
Key: JGRP-1493
URL: https://issues.jboss.org/browse/JGRP-1493
Project: JGroups
Issue Type: Feature Request
Affects Versions: 3.1
Reporter: David Hotham
Assignee: Bela Ban
Start with the following views:
- A, B and C all have {A,B,C}
- D has {B', D, A, C'}, where B' and C' are dead.
A decides to lead a merge (he's the only 'actual' coordinator). By the time
we've been through view-sanitization and so on and reached
getMergeDataFromSubgroupCoordinators(), coords are {D, C', A}.
Here A tries to send MERGE_REQ to those elements. However, A does not have a physical
address for C', and in fact nor does anyone else. So when trying to send the
MERGE_REQ to C', A will always spend a little over 5 seconds in
TP.sendToSingleMember() - trying and failing to discover that physical address.
Of course A won't get a response from C' either, so it will take another 5 seconds
for merge_rsps.waitForAllResponses to time out.
But that means that it's a sure thing that the MergeKiller will kick in first.
Therefore the merge can never progress.
(Presumably the situation would be even worse if there was more than one
I expect to work around this by tweaking the timings somewhere: probably in
startMergeKiller, so that the MergeKiller takes longer to be scheduled.
I'd think that the right fix would be to arrange that the MergeTask is not blocked by
TP having no physical address for a member.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:54 a.m.
[
https://issues.jboss.org/browse/JGRP-1493?page=com.atlassian.jira.plugin....
]
David Hotham updated JGRP-1493:
-------------------------------
Description:
Start with the following views:
- A, B and C all have {A,B,C}
- D has {B', D, A, C'}, where B' and C' are dead.
A decides to lead a merge (he's the only 'actual' coordinator). By the time
we've been through view-sanitization and so on and reached
getMergeDataFromSubgroupCoordinators(), coords are {D, C', A}.
Here A tries to send MERGE_REQ to those elements. However, A does not have a physical
address for C', and in fact nor does anyone else. So when trying to send the
MERGE_REQ to C', A will always spend a little over 5 seconds in
TP.sendToSingleMember() - trying and failing to discover that physical address.
Of course A won't get a response from C' either, so it will take another 5 seconds
for merge_rsps.waitForAllResponses to time out.
But that means that it's a sure thing that the MergeKiller will kick in first.
Therefore the merge can never progress.
(Presumably the situation would be even worse if D's view had contained further dead
members).
I expect to work around this by tweaking the timings somewhere: probably in
startMergeKiller, so that the MergeKiller takes longer to be scheduled.
I'd think that the right fix would be to arrange that the MergeTask is not blocked by
TP having no physical address for a member.
was:
Start with the following views:
- A, B and C all have {A,B,C}
- D has {B', D, A, C'}, where B' and C' are dead.
A decides to lead a merge (he's the only 'actual' coordinator). By the time
we've been through view-sanitization and so on and reached
getMergeDataFromSubgroupCoordinators(), coords are {D, C', A}.
Here A tries to send MERGE_REQ to those elements. However, A does not have a physical
address for C', and in fact nor does anyone else. So when trying to send the
MERGE_REQ to C', A will always spend a little over 5 seconds in
TP.sendToSingleMember() - trying and failing to discover that physical address.
Of course A won't get a response from C' either, so it will take another 5 seconds
for merge_rsps.waitForAllResponses to time out.
But that means that it's a sure thing that the MergeKiller will kick in first.
Therefore the merge can never progress.
(Presumably the situation would be even worse if there was more than one
I expect to work around this by tweaking the timings somewhere: probably in
startMergeKiller, so that the MergeKiller takes longer to be scheduled.
I'd think that the right fix would be to arrange that the MergeTask is not blocked by
TP having no physical address for a member.
Merge fails because failing to get physical address takes too long
------------------------------------------------------------------
Key: JGRP-1493
URL: https://issues.jboss.org/browse/JGRP-1493
Project: JGroups
Issue Type: Feature Request
Affects Versions: 3.1
Reporter: David Hotham
Assignee: Bela Ban
Start with the following views:
- A, B and C all have {A,B,C}
- D has {B', D, A, C'}, where B' and C' are dead.
A decides to lead a merge (he's the only 'actual' coordinator). By the time
we've been through view-sanitization and so on and reached
getMergeDataFromSubgroupCoordinators(), coords are {D, C', A}.
Here A tries to send MERGE_REQ to those elements. However, A does not have a physical
address for C', and in fact nor does anyone else. So when trying to send the
MERGE_REQ to C', A will always spend a little over 5 seconds in
TP.sendToSingleMember() - trying and failing to discover that physical address.
Of course A won't get a response from C' either, so it will take another 5
seconds for merge_rsps.waitForAllResponses to time out.
But that means that it's a sure thing that the MergeKiller will kick in first.
Therefore the merge can never progress.
(Presumably the situation would be even worse if D's view had contained further dead
members).
I expect to work around this by tweaking the timings somewhere: probably in
startMergeKiller, so that the MergeKiller takes longer to be scheduled.
I'd think that the right fix would be to arrange that the MergeTask is not blocked by
TP having no physical address for a member.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
11:31 a.m.
[
https://issues.jboss.org/browse/JGRP-1493?page=com.atlassian.jira.plugin....
]
David Hotham commented on JGRP-1493:
------------------------------------
Actually I've submitted a pull request - 59 - that makes that proposed 'right'
fix.
Merge fails because failing to get physical address takes too long
------------------------------------------------------------------
Key: JGRP-1493
URL: https://issues.jboss.org/browse/JGRP-1493
Project: JGroups
Issue Type: Feature Request
Affects Versions: 3.1
Reporter: David Hotham
Assignee: Bela Ban
Start with the following views:
- A, B and C all have {A,B,C}
- D has {B', D, A, C'}, where B' and C' are dead.
A decides to lead a merge (he's the only 'actual' coordinator). By the time
we've been through view-sanitization and so on and reached
getMergeDataFromSubgroupCoordinators(), coords are {D, C', A}.
Here A tries to send MERGE_REQ to those elements. However, A does not have a physical
address for C', and in fact nor does anyone else. So when trying to send the
MERGE_REQ to C', A will always spend a little over 5 seconds in
TP.sendToSingleMember() - trying and failing to discover that physical address.
Of course A won't get a response from C' either, so it will take another 5
seconds for merge_rsps.waitForAllResponses to time out.
But that means that it's a sure thing that the MergeKiller will kick in first.
Therefore the merge can never progress.
(Presumably the situation would be even worse if D's view had contained further dead
members).
I expect to work around this by tweaking the timings somewhere: probably in
startMergeKiller, so that the MergeKiller takes longer to be scheduled.
I'd think that the right fix would be to arrange that the MergeTask is not blocked by
TP having no physical address for a member.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
3:50 a.m.
[
https://issues.jboss.org/browse/JGRP-1493?page=com.atlassian.jira.plugin....
]
Bela Ban updated JGRP-1493:
---------------------------
Fix Version/s: 3.2
Merge fails because failing to get physical address takes too long
------------------------------------------------------------------
Key: JGRP-1493
URL: https://issues.jboss.org/browse/JGRP-1493
Project: JGroups
Issue Type: Feature Request
Affects Versions: 3.1
Reporter: David Hotham
Assignee: Bela Ban
Fix For: 3.2
Start with the following views:
- A, B and C all have {A,B,C}
- D has {B', D, A, C'}, where B' and C' are dead.
A decides to lead a merge (he's the only 'actual' coordinator). By the time
we've been through view-sanitization and so on and reached
getMergeDataFromSubgroupCoordinators(), coords are {D, C', A}.
Here A tries to send MERGE_REQ to those elements. However, A does not have a physical
address for C', and in fact nor does anyone else. So when trying to send the
MERGE_REQ to C', A will always spend a little over 5 seconds in
TP.sendToSingleMember() - trying and failing to discover that physical address.
Of course A won't get a response from C' either, so it will take another 5
seconds for merge_rsps.waitForAllResponses to time out.
But that means that it's a sure thing that the MergeKiller will kick in first.
Therefore the merge can never progress.
(Presumably the situation would be even worse if D's view had contained further dead
members).
I expect to work around this by tweaking the timings somewhere: probably in
startMergeKiller, so that the MergeKiller takes longer to be scheduled.
I'd think that the right fix would be to arrange that the MergeTask is not blocked by
TP having no physical address for a member.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:06 a.m.
[
https://issues.jboss.org/browse/JGRP-1493?page=com.atlassian.jira.plugin....
]
Bela Ban commented on JGRP-1493:
--------------------------------
Shouldn't this situation correct itself, when D drops the dead members in its view
after some time ? At least, if you use FD_ALL, D will exclude B' and C' after some
time, and become coordinator of {D,A}, and then the merge should succeed.
Re pull request #59: I don't like the solution of spawning a separate thread to send
the merge request. I'd rather add a new message flag to bypass fetching the physical
address, or make the timeout configurable...
Merge fails because failing to get physical address takes too long
------------------------------------------------------------------
Key: JGRP-1493
URL: https://issues.jboss.org/browse/JGRP-1493
Project: JGroups
Issue Type: Feature Request
Affects Versions: 3.1
Reporter: David Hotham
Assignee: Bela Ban
Fix For: 3.2
Start with the following views:
- A, B and C all have {A,B,C}
- D has {B', D, A, C'}, where B' and C' are dead.
A decides to lead a merge (he's the only 'actual' coordinator). By the time
we've been through view-sanitization and so on and reached
getMergeDataFromSubgroupCoordinators(), coords are {D, C', A}.
Here A tries to send MERGE_REQ to those elements. However, A does not have a physical
address for C', and in fact nor does anyone else. So when trying to send the
MERGE_REQ to C', A will always spend a little over 5 seconds in
TP.sendToSingleMember() - trying and failing to discover that physical address.
Of course A won't get a response from C' either, so it will take another 5
seconds for merge_rsps.waitForAllResponses to time out.
But that means that it's a sure thing that the MergeKiller will kick in first.
Therefore the merge can never progress.
(Presumably the situation would be even worse if D's view had contained further dead
members).
I expect to work around this by tweaking the timings somewhere: probably in
startMergeKiller, so that the MergeKiller takes longer to be scheduled.
I'd think that the right fix would be to arrange that the MergeTask is not blocked by
TP having no physical address for a member.
--
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
10:26 a.m.
[
https://issues.jboss.org/browse/JGRP-1493?page=com.atlassian.jira.plugin....
]
Bela Ban commented on JGRP-1493:
--------------------------------
Added who_has_cache_timeout and physical_addr_max_fetch_attempts
Merge fails because failing to get physical address takes too long
------------------------------------------------------------------
Key: JGRP-1493
URL: https://issues.jboss.org/browse/JGRP-1493
Project: JGroups
Issue Type: Feature Request
Affects Versions: 3.1
Reporter: David Hotham
Assignee: Bela Ban
Fix For: 3.2
Start with the following views:
- A, B and C all have {A,B,C}
- D has {B', D, A, C'}, where B' and C' are dead.
A decides to lead a merge (he's the only 'actual' coordinator). By the time
we've been through view-sanitization and so on and reached
getMergeDataFromSubgroupCoordinators(), coords are {D, C', A}.
Here A tries to send MERGE_REQ to those elements. However, A does not have a physical
address for C', and in fact nor does anyone else. So when trying to send the
MERGE_REQ to C', A will always spend a little over 5 seconds in
TP.sendToSingleMember() - trying and failing to discover that physical address.
Of course A won't get a response from C' either, so it will take another 5
seconds for merge_rsps.waitForAllResponses to time out.
But that means that it's a sure thing that the MergeKiller will kick in first.
Therefore the merge can never progress.
(Presumably the situation would be even worse if D's view had contained further dead
members).
I expect to work around this by tweaking the timings somewhere: probably in
startMergeKiller, so that the MergeKiller takes longer to be scheduled.
I'd think that the right fix would be to arrange that the MergeTask is not blocked by
TP having no physical address for a member.
--
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
10:37 a.m.
[
https://issues.jboss.org/browse/JGRP-1493?page=com.atlassian.jira.plugin....
]
Bela Ban commented on JGRP-1493:
--------------------------------
With physical_addr_max_fetch_attempts set to 1, we'd sleep 20 ms + random(500) ms,
*max* 520 ms before breaking out of the loop. OK ? I don't think we even need the
message flag to bypass physical address fetching...
Merge fails because failing to get physical address takes too long
------------------------------------------------------------------
Key: JGRP-1493
URL: https://issues.jboss.org/browse/JGRP-1493
Project: JGroups
Issue Type: Feature Request
Affects Versions: 3.1
Reporter: David Hotham
Assignee: Bela Ban
Fix For: 3.2
Start with the following views:
- A, B and C all have {A,B,C}
- D has {B', D, A, C'}, where B' and C' are dead.
A decides to lead a merge (he's the only 'actual' coordinator). By the time
we've been through view-sanitization and so on and reached
getMergeDataFromSubgroupCoordinators(), coords are {D, C', A}.
Here A tries to send MERGE_REQ to those elements. However, A does not have a physical
address for C', and in fact nor does anyone else. So when trying to send the
MERGE_REQ to C', A will always spend a little over 5 seconds in
TP.sendToSingleMember() - trying and failing to discover that physical address.
Of course A won't get a response from C' either, so it will take another 5
seconds for merge_rsps.waitForAllResponses to time out.
But that means that it's a sure thing that the MergeKiller will kick in first.
Therefore the merge can never progress.
(Presumably the situation would be even worse if D's view had contained further dead
members).
I expect to work around this by tweaking the timings somewhere: probably in
startMergeKiller, so that the MergeKiller takes longer to be scheduled.
I'd think that the right fix would be to arrange that the MergeTask is not blocked by
TP having no physical address for a member.
--
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
10:54 a.m.
[
https://issues.jboss.org/browse/JGRP-1493?page=com.atlassian.jira.plugin....
]
Bela Ban resolved JGRP-1493.
----------------------------
Resolution: Done
I think the combination of having to wait for 520 ms tops (if
physical_addr_max_fetch_attempts=1) and the fact that D should correct its view when
FD_ALL kicks in solve this issue.
Merge fails because failing to get physical address takes too long
------------------------------------------------------------------
Key: JGRP-1493
URL: https://issues.jboss.org/browse/JGRP-1493
Project: JGroups
Issue Type: Feature Request
Affects Versions: 3.1
Reporter: David Hotham
Assignee: Bela Ban
Fix For: 3.2
Start with the following views:
- A, B and C all have {A,B,C}
- D has {B', D, A, C'}, where B' and C' are dead.
A decides to lead a merge (he's the only 'actual' coordinator). By the time
we've been through view-sanitization and so on and reached
getMergeDataFromSubgroupCoordinators(), coords are {D, C', A}.
Here A tries to send MERGE_REQ to those elements. However, A does not have a physical
address for C', and in fact nor does anyone else. So when trying to send the
MERGE_REQ to C', A will always spend a little over 5 seconds in
TP.sendToSingleMember() - trying and failing to discover that physical address.
Of course A won't get a response from C' either, so it will take another 5
seconds for merge_rsps.waitForAllResponses to time out.
But that means that it's a sure thing that the MergeKiller will kick in first.
Therefore the merge can never progress.
(Presumably the situation would be even worse if D's view had contained further dead
members).
I expect to work around this by tweaking the timings somewhere: probably in
startMergeKiller, so that the MergeKiller takes longer to be scheduled.
I'd think that the right fix would be to arrange that the MergeTask is not blocked by
TP having no physical address for a member.
--
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
11:01 a.m.
[
https://issues.jboss.org/browse/JGRP-1493?page=com.atlassian.jira.plugin....
]
David Hotham commented on JGRP-1493:
------------------------------------
I have FD and FD_SOCK, but not FD_ALL. D doesn't exclude B' and C', and the
situation does not resolve itself.
I don't think that physical_addr_max_fetch_attempts is sufficient here:
- I agree that this limits the time it takes to look up one member
- But there may be more than one dead member. So you might repeatedly fail to find
physical addresses when sending MERGE_REQs, so that you still almost surely hit the merge
killer.
Perhaps the simplest answer would be to use FD_ALL. Is there any reason I wouldn't
want to include that in my stack (either in addition to or in place of the other FD
protocols)?
Merge fails because failing to get physical address takes too long
------------------------------------------------------------------
Key: JGRP-1493
URL: https://issues.jboss.org/browse/JGRP-1493
Project: JGroups
Issue Type: Feature Request
Affects Versions: 3.1
Reporter: David Hotham
Assignee: Bela Ban
Fix For: 3.2
Start with the following views:
- A, B and C all have {A,B,C}
- D has {B', D, A, C'}, where B' and C' are dead.
A decides to lead a merge (he's the only 'actual' coordinator). By the time
we've been through view-sanitization and so on and reached
getMergeDataFromSubgroupCoordinators(), coords are {D, C', A}.
Here A tries to send MERGE_REQ to those elements. However, A does not have a physical
address for C', and in fact nor does anyone else. So when trying to send the
MERGE_REQ to C', A will always spend a little over 5 seconds in
TP.sendToSingleMember() - trying and failing to discover that physical address.
Of course A won't get a response from C' either, so it will take another 5
seconds for merge_rsps.waitForAllResponses to time out.
But that means that it's a sure thing that the MergeKiller will kick in first.
Therefore the merge can never progress.
(Presumably the situation would be even worse if D's view had contained further dead
members).
I expect to work around this by tweaking the timings somewhere: probably in
startMergeKiller, so that the MergeKiller takes longer to be scheduled.
I'd think that the right fix would be to arrange that the MergeTask is not blocked by
TP having no physical address for a member.
--
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
11:22 a.m.
[
https://issues.jboss.org/browse/JGRP-1493?page=com.atlassian.jira.plugin....
]
David Hotham commented on JGRP-1493:
------------------------------------
I'm not completely convinced that FD_ALL will necessarily help either. Eg if D's
view had been {B', B, D, A, C'} then FD_ALL at D would never send SUSPECT events
at all (because D would never be the first of the eligible members).
Merge fails because failing to get physical address takes too long
------------------------------------------------------------------
Key: JGRP-1493
URL: https://issues.jboss.org/browse/JGRP-1493
Project: JGroups
Issue Type: Feature Request
Affects Versions: 3.1
Reporter: David Hotham
Assignee: Bela Ban
Fix For: 3.2
Start with the following views:
- A, B and C all have {A,B,C}
- D has {B', D, A, C'}, where B' and C' are dead.
A decides to lead a merge (he's the only 'actual' coordinator). By the time
we've been through view-sanitization and so on and reached
getMergeDataFromSubgroupCoordinators(), coords are {D, C', A}.
Here A tries to send MERGE_REQ to those elements. However, A does not have a physical
address for C', and in fact nor does anyone else. So when trying to send the
MERGE_REQ to C', A will always spend a little over 5 seconds in
TP.sendToSingleMember() - trying and failing to discover that physical address.
Of course A won't get a response from C' either, so it will take another 5
seconds for merge_rsps.waitForAllResponses to time out.
But that means that it's a sure thing that the MergeKiller will kick in first.
Therefore the merge can never progress.
(Presumably the situation would be even worse if D's view had contained further dead
members).
I expect to work around this by tweaking the timings somewhere: probably in
startMergeKiller, so that the MergeKiller takes longer to be scheduled.
I'd think that the right fix would be to arrange that the MergeTask is not blocked by
TP having no physical address for a member.
--
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
5:29 a.m.
[
https://issues.jboss.org/browse/JGRP-1493?page=com.atlassian.jira.plugin....
]
Bela Ban commented on JGRP-1493:
--------------------------------
First off, I think D should form a cluster of D and A even with FD (it will be faster with
FD_ALL):
- We have {B', D, A, C'}
- With FD, D pings A and A pings C'
- After not receiving acks from C' for a number of times, A excludes C' from its
ping set and starts sending out SUSPECT(C') messages
- A now starts pinging B'
- After some time, A excludes B' from its ping set and starts pinging D. It now starts
sending SUSPECT(C', B') messages
- D gets the SUSPECT(B') message, takes over as coordinator, creates view {D,A} and
installs it
So it'll take approximately 2 times (timeout * max_tries) milliseconds to establish
the new view.
With FD_ALL, this is faster: after timeout (+ (possibly) timeout_check_interval), B'
and C' will get excluded.
So using FD_ALL instead of FD should only be faster, but both protocols should end up with
view {D,A}. Once this happens, a merge should succeed.
If the view is not established, I'd rather investigate why this is the case, and not
work around this ! WDYT ?
I'll see if I can come up with a unit test for the root cause...
Merge fails because failing to get physical address takes too long
------------------------------------------------------------------
Key: JGRP-1493
URL: https://issues.jboss.org/browse/JGRP-1493
Project: JGroups
Issue Type: Feature Request
Affects Versions: 3.1
Reporter: David Hotham
Assignee: Bela Ban
Fix For: 3.2
Start with the following views:
- A, B and C all have {A,B,C}
- D has {B', D, A, C'}, where B' and C' are dead.
A decides to lead a merge (he's the only 'actual' coordinator). By the time
we've been through view-sanitization and so on and reached
getMergeDataFromSubgroupCoordinators(), coords are {D, C', A}.
Here A tries to send MERGE_REQ to those elements. However, A does not have a physical
address for C', and in fact nor does anyone else. So when trying to send the
MERGE_REQ to C', A will always spend a little over 5 seconds in
TP.sendToSingleMember() - trying and failing to discover that physical address.
Of course A won't get a response from C' either, so it will take another 5
seconds for merge_rsps.waitForAllResponses to time out.
But that means that it's a sure thing that the MergeKiller will kick in first.
Therefore the merge can never progress.
(Presumably the situation would be even worse if D's view had contained further dead
members).
I expect to work around this by tweaking the timings somewhere: probably in
startMergeKiller, so that the MergeKiller takes longer to be scheduled.
I'd think that the right fix would be to arrange that the MergeTask is not blocked by
TP having no physical address for a member.
--
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
6:18 a.m.
[
https://issues.jboss.org/browse/JGRP-1493?page=com.atlassian.jira.plugin....
]
David Hotham commented on JGRP-1493:
------------------------------------
A's view is {A,B,C}. A has no way to suspect C'.
Merge fails because failing to get physical address takes too long
------------------------------------------------------------------
Key: JGRP-1493
URL: https://issues.jboss.org/browse/JGRP-1493
Project: JGroups
Issue Type: Feature Request
Affects Versions: 3.1
Reporter: David Hotham
Assignee: Bela Ban
Fix For: 3.2
Start with the following views:
- A, B and C all have {A,B,C}
- D has {B', D, A, C'}, where B' and C' are dead.
A decides to lead a merge (he's the only 'actual' coordinator). By the time
we've been through view-sanitization and so on and reached
getMergeDataFromSubgroupCoordinators(), coords are {D, C', A}.
Here A tries to send MERGE_REQ to those elements. However, A does not have a physical
address for C', and in fact nor does anyone else. So when trying to send the
MERGE_REQ to C', A will always spend a little over 5 seconds in
TP.sendToSingleMember() - trying and failing to discover that physical address.
Of course A won't get a response from C' either, so it will take another 5
seconds for merge_rsps.waitForAllResponses to time out.
But that means that it's a sure thing that the MergeKiller will kick in first.
Therefore the merge can never progress.
(Presumably the situation would be even worse if D's view had contained further dead
members).
I expect to work around this by tweaking the timings somewhere: probably in
startMergeKiller, so that the MergeKiller takes longer to be scheduled.
I'd think that the right fix would be to arrange that the MergeTask is not blocked by
TP having no physical address for a member.
--
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
6:36 a.m.
[
https://issues.jboss.org/browse/JGRP-1493?page=com.atlassian.jira.plugin....
]
Bela Ban commented on JGRP-1493:
--------------------------------
Then use FD_ALL. It'll weed out B' and C' and end up with view {D,A}, which
will make the merge succeed.
Merge fails because failing to get physical address takes too long
------------------------------------------------------------------
Key: JGRP-1493
URL: https://issues.jboss.org/browse/JGRP-1493
Project: JGroups
Issue Type: Feature Request
Affects Versions: 3.1
Reporter: David Hotham
Assignee: Bela Ban
Fix For: 3.2
Start with the following views:
- A, B and C all have {A,B,C}
- D has {B', D, A, C'}, where B' and C' are dead.
A decides to lead a merge (he's the only 'actual' coordinator). By the time
we've been through view-sanitization and so on and reached
getMergeDataFromSubgroupCoordinators(), coords are {D, C', A}.
Here A tries to send MERGE_REQ to those elements. However, A does not have a physical
address for C', and in fact nor does anyone else. So when trying to send the
MERGE_REQ to C', A will always spend a little over 5 seconds in
TP.sendToSingleMember() - trying and failing to discover that physical address.
Of course A won't get a response from C' either, so it will take another 5
seconds for merge_rsps.waitForAllResponses to time out.
But that means that it's a sure thing that the MergeKiller will kick in first.
Therefore the merge can never progress.
(Presumably the situation would be even worse if D's view had contained further dead
members).
I expect to work around this by tweaking the timings somewhere: probably in
startMergeKiller, so that the MergeKiller takes longer to be scheduled.
I'd think that the right fix would be to arrange that the MergeTask is not blocked by
TP having no physical address for a member.
--
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
6:58 a.m.
[
https://issues.jboss.org/browse/JGRP-1493?page=com.atlassian.jira.plugin....
]
David Hotham commented on JGRP-1493:
------------------------------------
Per my last-but-one - will FD_ALL always help?
Merge fails because failing to get physical address takes too long
------------------------------------------------------------------
Key: JGRP-1493
URL: https://issues.jboss.org/browse/JGRP-1493
Project: JGroups
Issue Type: Feature Request
Affects Versions: 3.1
Reporter: David Hotham
Assignee: Bela Ban
Fix For: 3.2
Start with the following views:
- A, B and C all have {A,B,C}
- D has {B', D, A, C'}, where B' and C' are dead.
A decides to lead a merge (he's the only 'actual' coordinator). By the time
we've been through view-sanitization and so on and reached
getMergeDataFromSubgroupCoordinators(), coords are {D, C', A}.
Here A tries to send MERGE_REQ to those elements. However, A does not have a physical
address for C', and in fact nor does anyone else. So when trying to send the
MERGE_REQ to C', A will always spend a little over 5 seconds in
TP.sendToSingleMember() - trying and failing to discover that physical address.
Of course A won't get a response from C' either, so it will take another 5
seconds for merge_rsps.waitForAllResponses to time out.
But that means that it's a sure thing that the MergeKiller will kick in first.
Therefore the merge can never progress.
(Presumably the situation would be even worse if D's view had contained further dead
members).
I expect to work around this by tweaking the timings somewhere: probably in
startMergeKiller, so that the MergeKiller takes longer to be scheduled.
I'd think that the right fix would be to arrange that the MergeTask is not blocked by
TP having no physical address for a member.
--
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
4986
days inactive
5030
days old
13 comments
2 participants
participants (2)
-
Bela Ban (JIRA) -
David Hotham (JIRA)