[
https://issues.apache.org/jira/browse/IGNITE-426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14697156#comment-14697156
]
Semen Boikov edited comment on IGNITE-426 at 8/14/15 3:06 PM:
--------------------------------------------------------------
Found following problems working on this issue:
1. In tx cache it is not possible to use per-partition udpate counter since
partition can be update concurrently, one solution is to send counter values in
tx update messages.
2. In atomic cache obsevered following scenario:
- backup is preloading some partition
- primary updates value, sends message to backup
- backup receives message, does force key request, preloads already updated
entry from primary, during update on backup version check does not pass and
update on backup is ignored. As result backup queue and partition update
counter are not updated.
It is possible to detect this situation and increment update counter, but in
this case old value is also required on backup. One solution is to check if
backup is preloading partition and in this case send old value to backup in
update request, also in this case it is not possible to use CLOCK mode since
node initiating update does not have old value.
was (Author: sboikov):
Found following problems working on this issue:
1. In tx cache it is not possible to use per-partition udpate counter since
partition can be update concurrently, one solution is to send counter values in
tx update messages.
2. In atomic cache obsevered following scenario:
- backup is preloading some partition
- primary updates value, sends message to backup
- backup receives message, does force key request, preloads already updated
entry from primary, during update on backup version check does not pass and
update on backup is ignored. As result backup queue and partition update
counter are not updated. It is possible to detect this situation and increment
update counter, but in this case old value is also required on backup. One
solution is to check if backup is preloading partition and in this case send
old value to backup in update request, also in this case it is not possible to
use CLOCK mode since node initiating update does not have old value.
> Make sure continuous queries notifications are not missed in case primary
> node fails
> ------------------------------------------------------------------------------------
>
> Key: IGNITE-426
> URL: https://issues.apache.org/jira/browse/IGNITE-426
> Project: Ignite
> Issue Type: Sub-task
> Components: cache
> Reporter: Yakov Zhdanov
> Assignee: Semen Boikov
> Priority: Critical
> Fix For: ignite-1.4
>
>
> * Maintain updates queue on backup node(s) in addition to primary node.
> * If primary node crushes, this queue is flushed to listening clients.
> * To avoid notification duplicates we will have a per-partition update
> counter. Once an entry in some partition is updated, counter for this
> partition is incremented on both primary and backups. The value of this
> counter is also sent along with the update to the client, which also
> maintains the copy of this mapping. If at some moment it receives an update
> with the counter less than in its local map, this update is a duplicate and
> can be discarded.
> * To cleanup the backup queue we will use communication acks. When batch
> receival is acked by the client, we will send special ack message to backup
> nodes that will remove items that are not longer needed. This message has to
> contain partition to latest update counter map.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
