11:12 a.m.
Stale copies of gravitated data left in "xxx:DEAD trees
-------------------------------------------------------
Key: JBCACHE-1530
URL: https://jira.jboss.org/jira/browse/JBCACHE-1530
Project: JBoss Cache
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 3.2.0.BETA1
Reporter: Brian Stansberry
Assignee: Manik Surtani
There's a race that can result in a stale copy of gravitated data being left in a
"/BUDDY_BACKUP/xxx:DEAD" tree:
Scenario:
1) Data is store in /B_B/xxx/foo
2) xxx is leaving group
3) Gravitate data command for /B_B/xxx/foo comes in, result is returned
4) Buddy group re-formation thread move /B_B/xxx/foo to /B_B/xxx:DEAD/1/foo
5) DataGravitationCleanupCommand comes in for /B_B/xxx/foo which results in nothing
happening since the node is moved
A fix might involve some analysis of the backup fqn in the DataGravitationCleanupCommand,
try to detect this condition. Or perhaps tracking successful GravitationResult responses,
trying to match against the cleanup command.
As a quick workaround I'm going to investigate an algorithm on the
GravitateDataCommand sender side to not just accept the first successful result but rather
to compare all positive results, giving preference to:
1) A result from the main tree
2) A result from a non :DEAD buddy backup tree
3) A result from xxx:DEAD/2
4) A result from xxx:DEAD/1
--
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
11:16 a.m.
New subject: [JBoss JIRA] Commented: (JBCACHE-1530) Stale copies of gravitated data left in "xxx:DEAD trees
[
https://jira.jboss.org/jira/browse/JBCACHE-1530?page=com.atlassian.jira.p...
]
Manik Surtani commented on JBCACHE-1530:
----------------------------------------
The problem with scanning all results is that it could be slower. But then that's not
such an issue since the number of responses are always finite.
Stale copies of gravitated data left in "xxx:DEAD trees
-------------------------------------------------------
Key: JBCACHE-1530
URL: https://jira.jboss.org/jira/browse/JBCACHE-1530
Project: JBoss Cache
Issue Type: Bug
Security Level: Public(Everyone can see)
Affects Versions: 3.2.0.BETA1
Reporter: Brian Stansberry
Assignee: Manik Surtani
There's a race that can result in a stale copy of gravitated data being left in a
"/BUDDY_BACKUP/xxx:DEAD" tree:
Scenario:
1) Data is store in /B_B/xxx/foo
2) xxx is leaving group
3) Gravitate data command for /B_B/xxx/foo comes in, result is returned
4) Buddy group re-formation thread move /B_B/xxx/foo to /B_B/xxx:DEAD/1/foo
5) DataGravitationCleanupCommand comes in for /B_B/xxx/foo which results in nothing
happening since the node is moved
A fix might involve some analysis of the backup fqn in the DataGravitationCleanupCommand,
try to detect this condition. Or perhaps tracking successful GravitationResult responses,
trying to match against the cleanup command.
As a quick workaround I'm going to investigate an algorithm on the
GravitateDataCommand sender side to not just accept the first successful result but rather
to compare all positive results, giving preference to:
1) A result from the main tree
2) A result from a non :DEAD buddy backup tree
3) A result from xxx:DEAD/2
4) A result from xxx:DEAD/1
--
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
11:20 a.m.
New subject: [JBoss JIRA] Updated: (JBCACHE-1530) Stale copies of gravitated data left in "xxx:DEAD trees
[
https://jira.jboss.org/jira/browse/JBCACHE-1530?page=com.atlassian.jira.p...
]
Manik Surtani updated JBCACHE-1530:
-----------------------------------
Fix Version/s: 3.2.0.GA
Stale copies of gravitated data left in "xxx:DEAD trees
-------------------------------------------------------
Key: JBCACHE-1530
URL: https://jira.jboss.org/jira/browse/JBCACHE-1530
Project: JBoss Cache
Issue Type: Bug
Security Level: Public(Everyone can see)
Affects Versions: 3.2.0.BETA1
Reporter: Brian Stansberry
Assignee: Manik Surtani
Fix For: 3.2.0.GA
There's a race that can result in a stale copy of gravitated data being left in a
"/BUDDY_BACKUP/xxx:DEAD" tree:
Scenario:
1) Data is store in /B_B/xxx/foo
2) xxx is leaving group
3) Gravitate data command for /B_B/xxx/foo comes in, result is returned
4) Buddy group re-formation thread move /B_B/xxx/foo to /B_B/xxx:DEAD/1/foo
5) DataGravitationCleanupCommand comes in for /B_B/xxx/foo which results in nothing
happening since the node is moved
A fix might involve some analysis of the backup fqn in the DataGravitationCleanupCommand,
try to detect this condition. Or perhaps tracking successful GravitationResult responses,
trying to match against the cleanup command.
As a quick workaround I'm going to investigate an algorithm on the
GravitateDataCommand sender side to not just accept the first successful result but rather
to compare all positive results, giving preference to:
1) A result from the main tree
2) A result from a non :DEAD buddy backup tree
3) A result from xxx:DEAD/2
4) A result from xxx:DEAD/1
--
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:40 p.m.
New subject: [JBoss JIRA] Commented: (JBCACHE-1530) Stale copies of gravitated data left in "xxx:DEAD trees
[
https://jira.jboss.org/jira/browse/JBCACHE-1530?page=com.atlassian.jira.p...
]
Brian Stansberry commented on JBCACHE-1530:
-------------------------------------------
As discussed on IM: there's a cost to scanning all results, but it doesn't mean
extra time waiting for RPC responses, since it already waits for all.
Stale copies of gravitated data left in "xxx:DEAD trees
-------------------------------------------------------
Key: JBCACHE-1530
URL: https://jira.jboss.org/jira/browse/JBCACHE-1530
Project: JBoss Cache
Issue Type: Bug
Security Level: Public(Everyone can see)
Affects Versions: 3.2.0.BETA1
Reporter: Brian Stansberry
Assignee: Manik Surtani
Fix For: 3.2.0.GA
There's a race that can result in a stale copy of gravitated data being left in a
"/BUDDY_BACKUP/xxx:DEAD" tree:
Scenario:
1) Data is store in /B_B/xxx/foo
2) xxx is leaving group
3) Gravitate data command for /B_B/xxx/foo comes in, result is returned
4) Buddy group re-formation thread move /B_B/xxx/foo to /B_B/xxx:DEAD/1/foo
5) DataGravitationCleanupCommand comes in for /B_B/xxx/foo which results in nothing
happening since the node is moved
A fix might involve some analysis of the backup fqn in the DataGravitationCleanupCommand,
try to detect this condition. Or perhaps tracking successful GravitationResult responses,
trying to match against the cleanup command.
As a quick workaround I'm going to investigate an algorithm on the
GravitateDataCommand sender side to not just accept the first successful result but rather
to compare all positive results, giving preference to:
1) A result from the main tree
2) A result from a non :DEAD buddy backup tree
3) A result from xxx:DEAD/2
4) A result from xxx:DEAD/1
--
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:42 p.m.
New subject: [JBoss JIRA] Commented: (JBCACHE-1530) Stale copies of gravitated data left in "xxx:DEAD trees
[
https://jira.jboss.org/jira/browse/JBCACHE-1530?page=com.atlassian.jira.p...
]
Brian Stansberry commented on JBCACHE-1530:
-------------------------------------------
I'm woking on the workaround in the description. It seems it's not possible to
distinguish these:
1) A result from the main tree
2) A result from a non :DEAD buddy backup tree
This is because the GravitateResult does not include info on where the gravitated data was
stored.
Not ideal, but not critical; the real problem is distinguishing :DEAD results from
others.
Stale copies of gravitated data left in "xxx:DEAD trees
-------------------------------------------------------
Key: JBCACHE-1530
URL: https://jira.jboss.org/jira/browse/JBCACHE-1530
Project: JBoss Cache
Issue Type: Bug
Security Level: Public(Everyone can see)
Affects Versions: 3.2.0.BETA1
Reporter: Brian Stansberry
Assignee: Manik Surtani
Fix For: 3.2.0.GA
There's a race that can result in a stale copy of gravitated data being left in a
"/BUDDY_BACKUP/xxx:DEAD" tree:
Scenario:
1) Data is store in /B_B/xxx/foo
2) xxx is leaving group
3) Gravitate data command for /B_B/xxx/foo comes in, result is returned
4) Buddy group re-formation thread move /B_B/xxx/foo to /B_B/xxx:DEAD/1/foo
5) DataGravitationCleanupCommand comes in for /B_B/xxx/foo which results in nothing
happening since the node is moved
A fix might involve some analysis of the backup fqn in the DataGravitationCleanupCommand,
try to detect this condition. Or perhaps tracking successful GravitationResult responses,
trying to match against the cleanup command.
As a quick workaround I'm going to investigate an algorithm on the
GravitateDataCommand sender side to not just accept the first successful result but rather
to compare all positive results, giving preference to:
1) A result from the main tree
2) A result from a non :DEAD buddy backup tree
3) A result from xxx:DEAD/2
4) A result from xxx:DEAD/1
--
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:46 p.m.
New subject: [JBoss JIRA] Commented: (JBCACHE-1530) Stale copies of gravitated data left in "xxx:DEAD trees
[
https://jira.jboss.org/jira/browse/JBCACHE-1530?page=com.atlassian.jira.p...
]
Brian Stansberry commented on JBCACHE-1530:
-------------------------------------------
Also discussed on IM:
<brian> same scenario, but the node that gravitated the session has also picked the
first node as its new buddy
<brian> so, now that first node has 2 copies of session
<brian> under /B_B/xxx:DEAD/1/foo and /B_B/yyy/foo
<brian> later it gets a GravitateDataCommand and responds with the wrong one
Workaround I'm going to try implementing is to give preference to non-DEAD trees when
performing to GravitateDataCommand. Basically sort the set of /BUDDY_BACKUP children names
and scan through the sorted set.
Stale copies of gravitated data left in "xxx:DEAD trees
-------------------------------------------------------
Key: JBCACHE-1530
URL: https://jira.jboss.org/jira/browse/JBCACHE-1530
Project: JBoss Cache
Issue Type: Bug
Security Level: Public(Everyone can see)
Affects Versions: 3.2.0.BETA1
Reporter: Brian Stansberry
Assignee: Manik Surtani
Fix For: 3.2.0.GA
There's a race that can result in a stale copy of gravitated data being left in a
"/BUDDY_BACKUP/xxx:DEAD" tree:
Scenario:
1) Data is store in /B_B/xxx/foo
2) xxx is leaving group
3) Gravitate data command for /B_B/xxx/foo comes in, result is returned
4) Buddy group re-formation thread move /B_B/xxx/foo to /B_B/xxx:DEAD/1/foo
5) DataGravitationCleanupCommand comes in for /B_B/xxx/foo which results in nothing
happening since the node is moved
A fix might involve some analysis of the backup fqn in the DataGravitationCleanupCommand,
try to detect this condition. Or perhaps tracking successful GravitationResult responses,
trying to match against the cleanup command.
As a quick workaround I'm going to investigate an algorithm on the
GravitateDataCommand sender side to not just accept the first successful result but rather
to compare all positive results, giving preference to:
1) A result from the main tree
2) A result from a non :DEAD buddy backup tree
3) A result from xxx:DEAD/2
4) A result from xxx:DEAD/1
--
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:34 p.m.
New subject: [JBoss JIRA] Commented: (JBCACHE-1530) Stale copies of gravitated data left in "xxx:DEAD trees
[
https://jira.jboss.org/jira/browse/JBCACHE-1530?page=com.atlassian.jira.p...
]
Brian Stansberry commented on JBCACHE-1530:
-------------------------------------------
I've committed fixes along the lines described above. I don't have cycles to write
proper tests cases. :( But the existing testsuite passes. The QE testing of the AS
we're doing now will also help further validate this change.
Stale copies of gravitated data left in "xxx:DEAD trees
-------------------------------------------------------
Key: JBCACHE-1530
URL: https://jira.jboss.org/jira/browse/JBCACHE-1530
Project: JBoss Cache
Issue Type: Bug
Security Level: Public(Everyone can see)
Affects Versions: 3.2.0.BETA1
Reporter: Brian Stansberry
Assignee: Manik Surtani
Fix For: 3.2.0.GA
There's a race that can result in a stale copy of gravitated data being left in a
"/BUDDY_BACKUP/xxx:DEAD" tree:
Scenario:
1) Data is store in /B_B/xxx/foo
2) xxx is leaving group
3) Gravitate data command for /B_B/xxx/foo comes in, result is returned
4) Buddy group re-formation thread move /B_B/xxx/foo to /B_B/xxx:DEAD/1/foo
5) DataGravitationCleanupCommand comes in for /B_B/xxx/foo which results in nothing
happening since the node is moved
A fix might involve some analysis of the backup fqn in the DataGravitationCleanupCommand,
try to detect this condition. Or perhaps tracking successful GravitationResult responses,
trying to match against the cleanup command.
As a quick workaround I'm going to investigate an algorithm on the
GravitateDataCommand sender side to not just accept the first successful result but rather
to compare all positive results, giving preference to:
1) A result from the main tree
2) A result from a non :DEAD buddy backup tree
3) A result from xxx:DEAD/2
4) A result from xxx:DEAD/1
--
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:31 p.m.
New subject: [JBoss JIRA] Commented: (JBCACHE-1530) Stale copies of gravitated data left in "xxx:DEAD trees
[
https://jira.jboss.org/jira/browse/JBCACHE-1530?page=com.atlassian.jira.p...
]
Brian Stansberry commented on JBCACHE-1530:
-------------------------------------------
Argh; yet another twist. Assume the stale /B_B/xxx:DEAD/1/foo is stored on node A. And
then later the user fails over to A. The local baclup tree is searched first for data
before any GravitateDataCommand is sent to other nodes, so the stale data will be used.
Stale copies of gravitated data left in "xxx:DEAD trees
-------------------------------------------------------
Key: JBCACHE-1530
URL: https://jira.jboss.org/jira/browse/JBCACHE-1530
Project: JBoss Cache
Issue Type: Bug
Security Level: Public(Everyone can see)
Affects Versions: 3.2.0.BETA1
Reporter: Brian Stansberry
Assignee: Manik Surtani
Fix For: 3.2.0.GA
There's a race that can result in a stale copy of gravitated data being left in a
"/BUDDY_BACKUP/xxx:DEAD" tree:
Scenario:
1) Data is store in /B_B/xxx/foo
2) xxx is leaving group
3) Gravitate data command for /B_B/xxx/foo comes in, result is returned
4) Buddy group re-formation thread move /B_B/xxx/foo to /B_B/xxx:DEAD/1/foo
5) DataGravitationCleanupCommand comes in for /B_B/xxx/foo which results in nothing
happening since the node is moved
A fix might involve some analysis of the backup fqn in the DataGravitationCleanupCommand,
try to detect this condition. Or perhaps tracking successful GravitationResult responses,
trying to match against the cleanup command.
As a quick workaround I'm going to investigate an algorithm on the
GravitateDataCommand sender side to not just accept the first successful result but rather
to compare all positive results, giving preference to:
1) A result from the main tree
2) A result from a non :DEAD buddy backup tree
3) A result from xxx:DEAD/2
4) A result from xxx:DEAD/1
--
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
5:30 p.m.
New subject: [JBoss JIRA] Commented: (JBCACHE-1530) Stale copies of gravitated data left in "xxx:DEAD trees
[
https://jira.jboss.org/jira/browse/JBCACHE-1530?page=com.atlassian.jira.p...
]
Brian Stansberry commented on JBCACHE-1530:
-------------------------------------------
To get around the last twist above, having the DataGravitationCleanup command clean the
defunct data trees looks like the only way to go. I've implemented this with a fairly
kludgey mechanism to limit it to about a minute or so after the defunct data tree is
created. After that much time has elapsed any GravitateResult should have come from the
defunct data tree.
Stale copies of gravitated data left in "xxx:DEAD trees
-------------------------------------------------------
Key: JBCACHE-1530
URL: https://jira.jboss.org/jira/browse/JBCACHE-1530
Project: JBoss Cache
Issue Type: Bug
Security Level: Public(Everyone can see)
Affects Versions: 3.2.0.BETA1
Reporter: Brian Stansberry
Assignee: Manik Surtani
Fix For: 3.2.0.GA
There's a race that can result in a stale copy of gravitated data being left in a
"/BUDDY_BACKUP/xxx:DEAD" tree:
Scenario:
1) Data is store in /B_B/xxx/foo
2) xxx is leaving group
3) Gravitate data command for /B_B/xxx/foo comes in, result is returned
4) Buddy group re-formation thread move /B_B/xxx/foo to /B_B/xxx:DEAD/1/foo
5) DataGravitationCleanupCommand comes in for /B_B/xxx/foo which results in nothing
happening since the node is moved
A fix might involve some analysis of the backup fqn in the DataGravitationCleanupCommand,
try to detect this condition. Or perhaps tracking successful GravitationResult responses,
trying to match against the cleanup command.
As a quick workaround I'm going to investigate an algorithm on the
GravitateDataCommand sender side to not just accept the first successful result but rather
to compare all positive results, giving preference to:
1) A result from the main tree
2) A result from a non :DEAD buddy backup tree
3) A result from xxx:DEAD/2
4) A result from xxx:DEAD/1
--
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
10:17 a.m.
New subject: [JBoss JIRA] Resolved: (JBCACHE-1530) Stale copies of gravitated data left in "xxx:DEAD trees
[
https://jira.jboss.org/jira/browse/JBCACHE-1530?page=com.atlassian.jira.p...
]
Manik Surtani resolved JBCACHE-1530.
------------------------------------
Fix Version/s: 3.2.0.CR1
Resolution: Done
Assignee: Brian Stansberry (was: Manik Surtani)
Stale copies of gravitated data left in "xxx:DEAD trees
-------------------------------------------------------
Key: JBCACHE-1530
URL: https://jira.jboss.org/jira/browse/JBCACHE-1530
Project: JBoss Cache
Issue Type: Bug
Security Level: Public(Everyone can see)
Affects Versions: 3.2.0.BETA1
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 3.2.0.GA, 3.2.0.CR1
There's a race that can result in a stale copy of gravitated data being left in a
"/BUDDY_BACKUP/xxx:DEAD" tree:
Scenario:
1) Data is store in /B_B/xxx/foo
2) xxx is leaving group
3) Gravitate data command for /B_B/xxx/foo comes in, result is returned
4) Buddy group re-formation thread move /B_B/xxx/foo to /B_B/xxx:DEAD/1/foo
5) DataGravitationCleanupCommand comes in for /B_B/xxx/foo which results in nothing
happening since the node is moved
A fix might involve some analysis of the backup fqn in the DataGravitationCleanupCommand,
try to detect this condition. Or perhaps tracking successful GravitationResult responses,
trying to match against the cleanup command.
As a quick workaround I'm going to investigate an algorithm on the
GravitateDataCommand sender side to not just accept the first successful result but rather
to compare all positive results, giving preference to:
1) A result from the main tree
2) A result from a non :DEAD buddy backup tree
3) A result from xxx:DEAD/2
4) A result from xxx:DEAD/1
--
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
10:22 p.m.
New subject: [JBoss JIRA] Reopened: (JBCACHE-1530) Stale copies of gravitated data left in "xxx:DEAD trees
[
https://jira.jboss.org/jira/browse/JBCACHE-1530?page=com.atlassian.jira.p...
]
Brian Stansberry reopened JBCACHE-1530:
---------------------------------------
Found problems with the logic for cleaning dead trees.
Stale copies of gravitated data left in "xxx:DEAD trees
-------------------------------------------------------
Key: JBCACHE-1530
URL: https://jira.jboss.org/jira/browse/JBCACHE-1530
Project: JBoss Cache
Issue Type: Bug
Security Level: Public(Everyone can see)
Affects Versions: 3.2.0.BETA1
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 3.2.0.CR1, 3.2.0.GA
There's a race that can result in a stale copy of gravitated data being left in a
"/BUDDY_BACKUP/xxx:DEAD" tree:
Scenario:
1) Data is store in /B_B/xxx/foo
2) xxx is leaving group
3) Gravitate data command for /B_B/xxx/foo comes in, result is returned
4) Buddy group re-formation thread move /B_B/xxx/foo to /B_B/xxx:DEAD/1/foo
5) DataGravitationCleanupCommand comes in for /B_B/xxx/foo which results in nothing
happening since the node is moved
A fix might involve some analysis of the backup fqn in the DataGravitationCleanupCommand,
try to detect this condition. Or perhaps tracking successful GravitationResult responses,
trying to match against the cleanup command.
As a quick workaround I'm going to investigate an algorithm on the
GravitateDataCommand sender side to not just accept the first successful result but rather
to compare all positive results, giving preference to:
1) A result from the main tree
2) A result from a non :DEAD buddy backup tree
3) A result from xxx:DEAD/2
4) A result from xxx:DEAD/1
--
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:57 a.m.
New subject: [JBoss JIRA] Closed: (JBCACHE-1530) Stale copies of gravitated data left in "xxx:DEAD trees
[
https://jira.jboss.org/jira/browse/JBCACHE-1530?page=com.atlassian.jira.p...
]
Brian Stansberry closed JBCACHE-1530.
-------------------------------------
Fix Version/s: (was: 3.2.0.CR1)
Resolution: Done
Fixed bugs, added test.
Stale copies of gravitated data left in "xxx:DEAD trees
-------------------------------------------------------
Key: JBCACHE-1530
URL: https://jira.jboss.org/jira/browse/JBCACHE-1530
Project: JBoss Cache
Issue Type: Bug
Security Level: Public(Everyone can see)
Affects Versions: 3.2.0.BETA1
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 3.2.0.GA
There's a race that can result in a stale copy of gravitated data being left in a
"/BUDDY_BACKUP/xxx:DEAD" tree:
Scenario:
1) Data is store in /B_B/xxx/foo
2) xxx is leaving group
3) Gravitate data command for /B_B/xxx/foo comes in, result is returned
4) Buddy group re-formation thread move /B_B/xxx/foo to /B_B/xxx:DEAD/1/foo
5) DataGravitationCleanupCommand comes in for /B_B/xxx/foo which results in nothing
happening since the node is moved
A fix might involve some analysis of the backup fqn in the DataGravitationCleanupCommand,
try to detect this condition. Or perhaps tracking successful GravitationResult responses,
trying to match against the cleanup command.
As a quick workaround I'm going to investigate an algorithm on the
GravitateDataCommand sender side to not just accept the first successful result but rather
to compare all positive results, giving preference to:
1) A result from the main tree
2) A result from a non :DEAD buddy backup tree
3) A result from xxx:DEAD/2
4) A result from xxx:DEAD/1
--
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
5611
days inactive
5615
days old
jbosscache-issues@lists.jboss.org
11 comments
2 participants
participants (2)
-
Brian Stansberry (JIRA) -
Manik Surtani (JIRA)