[infinispan-issues] [JBoss JIRA] (ISPN-1965) Some entries not available during view change

[RH Bugzilla Integration (JIRA)]

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

RH Bugzilla Integration commented on ISPN-1965:
-----------------------------------------------

Dan Berindei <dberinde at redhat.com> made a comment on [bug 808623|https://bugzilla.redhat.com/show_bug.cgi?id=808623]

Infinispan doesn't guarantee anything when when more than numOwner nodes leave the cluster. When we have a split in a 4-nodes cluster and each partition has 2 nodes, that means each partition will have lost numOwners nodes and Infinispan can't guarantee that all the pre-existing keys will be kept in both partitions.

When the partitions merge and we get a single cluster, the key values are usually preserved in the new cluster - assuming that no client modifies the values during the network split. If a client modified a key during the split, Infinispan doesn't offer any guarantees: a client could retrieve the old value or the new value (and it could retrieve the old value after it retrieved the new value). This policy applies for creation/removal as well, if we equate a missing key with a null value.
                
> Some entries not available during view change
> ---------------------------------------------
>
>                 Key: ISPN-1965
>                 URL: https://issues.jboss.org/browse/ISPN-1965
>             Project: Infinispan
>          Issue Type: Bug
>    Affects Versions: 5.1.3.FINAL
>            Reporter: Michal Linhard
>            Assignee: Dan Berindei
>
> In the 4 node, dist mode, num-owners=2, elasticity test
> http://www.qa.jboss.com/~mlinhard/hyperion/run44-elas-dist/
> there is a cca 90 sec period of time where clients get null responses to GET
> requests on entries that should exist in the cache.
> first occurence:
> hyperion1139.log 05:31:01,202 286.409
> last occurence:
> hyperion1135.log 05:32:45,441 390.648
> total occurence count: (in all 19 driver nodes)
> 152241
> (this doesn't mean it happens for 152K keys, because each key is retried after
> erroneous attempt)
> data doesn't seem to be lost, because these errors cease after a while and
> number of entries returns back to normal (see cache_entries.csv)
> this happens approximately in the period between node0001 is killed and cluster
> {node0002 - node0004} is formed (and shortly after).

--
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