[infinispan-issues] [JBoss JIRA] (ISPN-4504) Topology id is not properly set on ClusteredGetCommands

Dan Berindei (JIRA) issues at jboss.org
Fri Jul 11 10:43:24 EDT 2014


    [ https://issues.jboss.org/browse/ISPN-4504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984273#comment-12984273 ] 

Dan Berindei edited comment on ISPN-4504 at 7/11/14 10:42 AM:
--------------------------------------------------------------

It turns out scenarios 5 and 7 should not be valid. I've rewritten the summary in RemoteGetDuringStateTransferTest, I think the new look makes it clear when we expect the originator to retry:

   T = initial topology, T1  = rebalance started but we have no data yet, T2  = rebalance finished

   | scenario    | old scenario | first request | process request 1 | receive response 1 | retry | process request 2 | receive response 2 |
   | 010    | 1   | T0            | 1:T1              | T0                 | N     |                   |                    |
   | 011    | 2   | T0            | 1:T1              | T1                 | N     |                   |                    |
   | [1]    |     | T0            | 1:T1              | T2                 | N     |                   |                    |
   | [2]    |     | T0            | 1:T2              | T0                 | N/A   |                   |                    |
   | [3]    |     | T0            | 1:T2              | T1                 | Y     | 2:T0              | N/A                |
   | 021_11 | 4   | T0            | 1:T2              | T1                 | Y     | 2:T1              | T1                 |
   | [1]    | 4   | T0            | 1:T2              | T1                 | Y     | 2:T1              | T2                 |
   | 021_21 | 4.1 | T0            | 1:T2              | T1                 | Y     | 2:T2              | T1                 |
   | [1]    | 4.1 | T0            | 1:T2              | T1                 | Y     | 2:T2              | T2                 |
   | [4]    | 5   | T0            | 1:T2              | T2                 | Y     | 2:T1              | N/A                |
   | 022_22 | 5.1 | T0            | 1:T2              | T2                 | Y     | 2:T2              | T2                 |
   | 111    | 3   | T1            | 1:T1              | T1                 | N     |                   |                    |
   | [1]    |     | T1            | 1:T1              | T2                 | N     |                   |                    |
   | 121_11 | 6.1 | T1            | 1:T2              | T1                 | Y     | 2:T1              | T1                 |
   | [1]    |     | T1            | 1:T2              | T1                 | Y     | 2:T1              | T2                 |
   | 121_22 | 6   | T1            | 1:T2              | T1                 | Y     | 2:T2              | T2                 |
   | [4]    | 7   | T1            | 1:T2              | T2                 | Y     | 2:T1              | N/A                |
   | 122_22 | 7.1 | T1            | 1:T2              | T2                 | Y     | 2:T2              | T2                 |

   [1] too similar to the previous scenario
   [2] impossible because we can't have T0 on one node and T2 on another node at the same time
   [3] impossible because the 2nd request would block for until the target installs T1
   [4] impossible because the 2nd request would block for until the target installs T2

I'm also thinking of adding a separate test with non-existent keys, something like this:

   | scenario    | first request | process request 1 | receive response 1 | retry | process request 2 | receive response 2 |
   | 010    | T0            | 1:T1              | T0                 | N     |                   |                    |
   | 011_11 | T0            | 1:T1              | T1                 | Y     | 2:T1              | T1                 |
   | [4]    | T0            | 1:T1              | T2                 | Y     | 2:T1              | N/A                |
   | 011_22 | T0            | 1:T1              | T2                 | Y     | 2:T2              | T2                 |
   | [2]    | T0            | 1:T2              | T0                 | N/A   |                   |                    |
   | [3]    | T0            | 1:T2              | T1                 | Y     | 2:T0              | N/A                |
   | 021_11 | T0            | 1:T2              | T1                 | Y     | 2:T1              | T1                 |
   | [1]    | T0            | 1:T2              | T1                 | Y     | 2:T1              | T2                 |
   | 021_21 | T0            | 1:T2              | T1                 | Y     | 2:T2              | T1                 |
   | [1]    | T0            | 1:T2              | T1                 | Y     | 2:T2              | T2                 |
   | [4]    | T0            | 1:T2              | T2                 | Y     | 2:T1              | N/A                |
   | 022_22 | T0            | 1:T2              | T2                 | Y     | 2:T2              | T2                 |
   | 111    | T1            | 1:T1              | T1                 | N     |                   |                    |
   | [4]    | T1            | 1:T1              | T2                 | Y     | 2:T1              | N/A                |
   | 112_22 | T1            | 1:T1              | T2                 | Y     | 2:T2              | T2                 |
   | 121_11 | T1            | 1:T2              | T1                 | Y     | 2:T1              | T1                 |
   | [1]    | T1            | 1:T2              | T1                 | Y     | 2:T1              | T2                 |
   | 121_22 | T1            | 1:T2              | T1                 | Y     | 2:T2              | T2                 |
   | [4]    | T1            | 1:T2              | T2                 | Y     | 2:T1              | N/A                |
   | 122_22 | T1            | 1:T2              | T2                 | Y     | 2:T2              | T2                 |



was (Author: dan.berindei):
It turns out scenarios 5 and 7 should not be valid. I've rewritten the summary in RemoteGetDuringStateTransferTest, I think the new look makes it clear when we expect the originator to retry:

   T = initial topology, T1  = rebalance started but we have no data yet, T1.5 rebalance started and we have data, T2  = rebalance finished

   | scenario    | old scenario | first request | process request 1 | receive response 1 | retry | process request 2 | receive response 2 |
   | 010    | 1   | T0            | 1:T1              | T0                 | N     |                   |                    |
   | 011    | 2   | T0            | 1:T1              | T1                 | N     |                   |                    |
   | [1]    |     | T0            | 1:T1              | T2                 | N     |                   |                    |
   | [2]    |     | T0            | 1:T2              | T0                 | N/A   |                   |                    |
   | [3]    |     | T0            | 1:T2              | T1                 | Y     | 2:T0              | N/A                |
   | 021_11 | 4   | T0            | 1:T2              | T1                 | Y     | 2:T1              | T1                 |
   | [1]    | 4   | T0            | 1:T2              | T1                 | Y     | 2:T1              | T2                 |
   | 021_21 | 4.1 | T0            | 1:T2              | T1                 | Y     | 2:T2              | T1                 |
   | [1]    | 4.1 | T0            | 1:T2              | T1                 | Y     | 2:T2              | T2                 |
   | [4]    | 5   | T0            | 1:T2              | T2                 | Y     | 2:T1              | N/A                |
   | 022_22 | 5.1 | T0            | 1:T2              | T2                 | Y     | 2:T2              | T2                 |
   | 111    | 3   | T1            | 1:T1              | T1                 | N     |                   |                    |
   | [1]    |     | T1            | 1:T1              | T2                 | N     |                   |                    |
   | 121_11 | 6.1 | T1            | 1:T2              | T1                 | Y     | 2:T1              | T1                 |
   | [1]    |     | T1            | 1:T2              | T1                 | Y     | 2:T1              | T2                 |
   | 121_22 | 6   | T1            | 1:T2              | T1                 | Y     | 2:T2              | T2                 |
   | [4]    | 7   | T1            | 1:T2              | T2                 | Y     | 2:T1              | N/A                |
   | 122_22 | 7.1 | T1            | 1:T2              | T2                 | Y     | 2:T2              | T2                 |

   [1] too similar to the previous scenario
   [2] impossible because we can't have T0 on one node and T2 on another node at the same time
   [3] impossible because the 2nd request would block for until the target installs T1
   [4] impossible because the 2nd request would block for until the target installs T2

I'm also thinking of adding a separate test with non-existent keys, something like this:

   | scenario    | first request | process request 1 | receive response 1 | retry | process request 2 | receive response 2 |
   | 010    | T0            | 1:T1              | T0                 | N     |                   |                    |
   | 011_11 | T0            | 1:T1              | T1                 | Y     | 2:T1              | T1                 |
   | [4]    | T0            | 1:T1              | T2                 | Y     | 2:T1              | N/A                |
   | 011_22 | T0            | 1:T1              | T2                 | Y     | 2:T2              | T2                 |
   | [2]    | T0            | 1:T2              | T0                 | N/A   |                   |                    |
   | [3]    | T0            | 1:T2              | T1                 | Y     | 2:T0              | N/A                |
   | 021_11 | T0            | 1:T2              | T1                 | Y     | 2:T1              | T1                 |
   | [1]    | T0            | 1:T2              | T1                 | Y     | 2:T1              | T2                 |
   | 021_21 | T0            | 1:T2              | T1                 | Y     | 2:T2              | T1                 |
   | [1]    | T0            | 1:T2              | T1                 | Y     | 2:T2              | T2                 |
   | [4]    | T0            | 1:T2              | T2                 | Y     | 2:T1              | N/A                |
   | 022_22 | T0            | 1:T2              | T2                 | Y     | 2:T2              | T2                 |
   | 111    | T1            | 1:T1              | T1                 | N     |                   |                    |
   | [4]    | T1            | 1:T1              | T2                 | Y     | 2:T1              | N/A                |
   | 112_22 | T1            | 1:T1              | T2                 | Y     | 2:T2              | T2                 |
   | 121_11 | T1            | 1:T2              | T1                 | Y     | 2:T1              | T1                 |
   | [1]    | T1            | 1:T2              | T1                 | Y     | 2:T1              | T2                 |
   | 121_22 | T1            | 1:T2              | T1                 | Y     | 2:T2              | T2                 |
   | [4]    | T1            | 1:T2              | T2                 | Y     | 2:T1              | N/A                |
   | 122_22 | T1            | 1:T2              | T2                 | Y     | 2:T2              | T2                 |


> Topology id is not properly set on ClusteredGetCommands
> -------------------------------------------------------
>
>                 Key: ISPN-4504
>                 URL: https://issues.jboss.org/browse/ISPN-4504
>             Project: Infinispan
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Core
>    Affects Versions: 7.0.0.Alpha4
>            Reporter: Dan Berindei
>            Assignee: Dan Berindei
>             Fix For: 7.0.0.Alpha5
>
>
> Because the topology id is not properly set on ClusteredGetCommands, they don't wait for the sender's topology to be installed on the target.
> I have tried to fix this while implementing a fix for ISPN-4503. My solution caused 2 failures in RemoteGetDuringStateTransferTest, scenarios 5 and 7::
> |   sc | currentTopologyId         | currentTopologyId + 1 (rebalance)     | currentTopologyId + 2 (finish) |
> |   5  | 0:remoteGet               | 2:sendReply                           | 0:receiveReply, 1:sendReply |
> |   7  |                           | 0:remoteGet, 2: sendReply             | 0:receiveReply, 1:sendReply |



--
This message was sent by Atlassian JIRA
(v6.2.6#6264)


More information about the infinispan-issues mailing list