[ https://issues.jboss.org/browse/ISPN-1965?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-1965: ----------------------------------------------- Misha H. Ali <mhusnain(a)redhat.com&gt; made a comment on [bug 808623|https://bugzilla.redhat.com/show_bug.cgi?id=808623] Technical note updated. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -1,5 +1 @@ -CCFR - Michal Linhard. If this only pertains to Infiniband/RDMA, then this is a low prio and non-critical to JDG 6. +When the view is changed, some entries are unavailable to some clients, despite existing in the cluster and being loaded in the data loading phase. The total number of entries (retrieved by JMX) is correct, therefore the missing entries are not lost. This error occurs for a brief period of time and then ceases.- -This is a new bug not yet thoroughly investigated. - -I can only tell the symptoms: during a view change (probably when a partition occurs) some entries aren't available to certain clients although they exist somewhere in the cluster - it was loaded in the data loading phase. The data isn't lost though. Total number of entries (retrieved via JMX) is correct throughout the test. These errors occurs only during a brief period of time and then cease. -- 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

[ https://issues.jboss.org/browse/ISPN-1965?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-1965: ----------------------------------------------- Misha H. Ali <mhusnain(a)redhat.com&gt; made a comment on [bug 808623|https://bugzilla.redhat.com/show_bug.cgi?id=808623] Technical note updated. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -1 +1,3 @@ -When the view is changed, some entries are unavailable to some clients, despite existing in the cluster and being loaded in the data loading phase. The total number of entries (retrieved by JMX) is correct, therefore the missing entries are not lost. This error occurs for a brief period of time and then ceases.+When a number of nodes larger than the value of numOwner leave a cluster, JBoss Data Grid cannot guarantee that all key values are preserved. In a four node cluster, each partition has two nodes. As a result, each partition loses a number of nodes that equals the value of numOwner and keys that exist prior to the nodes leaving the cluster may not be preserved in both partitions. + +When partitions are merged into a single cluster, key values are preserved in the new cluster (assuming that no clients modified these values during the network split). If a client modified a key during the network split, the old value may be retrieved, the new value may be retrieved, and in some cases the old value may be retrieved after the old value is retrieved. This policy applies to creation and removal as well, if the missing key is equated with a null value.. -- 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

[ https://issues.jboss.org/browse/ISPN-1965?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-1965: ----------------------------------------------- Misha H. Ali <mhusnain(a)redhat.com&gt; made a comment on [bug 808623|https://bugzilla.redhat.com/show_bug.cgi?id=808623] Technical note updated. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -1,4 +1,12 @@ -When a number of nodes larger than the value of numOwner leave a cluster, JBoss Data Grid cannot guarantee that all key values are preserved. In a four node cluster, each partition has two nodes. As a result, each partition loses a number of nodes that equals the value of numOwner and keys that exist prior to the nodes leaving the cluster may not be preserved in both partitions. +In rare circumstances, when a node leaves the cluster, instead of going +directly to a new cluster view that displays all nodes save the note that has departed, the cluster splits into two partitions which then merge after a short amount of time. During this time, some nodes do not have access to all the data that previously existed in the cache. After the merge, all nodes regain access to all the data, but changes made during the split may be lost or be visible only to a part of the cluster. </para> <para> -When partitions are merged into a single cluster, key values are preserved in the new cluster (assuming that no clients modified these values during the network split). If a client modified a key during the network split, the old value may be retrieved, the new value may be retrieved, and in some cases the old value may be retrieved after the old value is retrieved. This policy applies to creation and removal as well, if the missing key is equated with a null value..+Normally, when the view changes because a node joins or leaves, the cache data is +rebalanced on the new cluster members. However, if the number of nodes that leaves the cluster in quick succession equals or is greater than the value of numOwners, keys for the departed nodes are lost. This occurs during a network split as well - regardless of the reasons for the partitions forming, at least one partition will not have all the data (assuming cluster size is greater than numOwners). +</para> +<para> +While there are multiple partitions, each one can make changes to the data +independently, so a remote client will see inconsistencies in the data. When +merging, JBoss Data Grid does not attempt to resolve these inconsistencies, so +different nodes may hold different values even after the merge. -- 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

[ https://issues.jboss.org/browse/ISPN-1965?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-1965: ----------------------------------------------- Misha H. Ali <mhusnain(a)redhat.com&gt; made a comment on [bug 808623|https://bugzilla.redhat.com/show_bug.cgi?id=808623] Technical note updated. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -1,12 +1,9 @@ -In rare circumstances, when a node leaves the cluster, instead of going -directly to a new cluster view that displays all nodes save the note that has departed, the cluster splits into two partitions which then merge after a short amount of time. During this time, some nodes do not have access to all the data that previously existed in the cache. After the merge, all nodes regain access to all the data, but changes made during the split may be lost or be visible only to a part of the cluster. +In rare circumstances, when a node leaves the cluster, instead of going directly to a new cluster view that displays all nodes save the note that has departed, the cluster splits into two partitions which then merge after a short amount of time. During this time, some nodes do not have access to all the data that previously existed in the cache. After the merge, all nodes regain access to all the data, but changes made during the split may be lost or be visible only to a part of the cluster. </para> <para> Normally, when the view changes because a node joins or leaves, the cache data is rebalanced on the new cluster members. However, if the number of nodes that leaves the cluster in quick succession equals or is greater than the value of numOwners, keys for the departed nodes are lost. This occurs during a network split as well - regardless of the reasons for the partitions forming, at least one partition will not have all the data (assuming cluster size is greater than numOwners). </para> <para> -While there are multiple partitions, each one can make changes to the data -independently, so a remote client will see inconsistencies in the data. When -merging, JBoss Data Grid does not attempt to resolve these inconsistencies, so +While there are multiple partitions, each one can make changes to the data independently, so a remote client will see inconsistencies in the data. When merging, JBoss Data Grid does not attempt to resolve these inconsistencies, so different nodes may hold different values even after the merge. -- 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