[
https://issues.apache.org/jira/browse/IGNITE-15222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-15222:
---------------------------------
Description:
Metastorage's cursor commands next and hasNext are implemented using
{{CursorNextCommand}} and {{CursorHasNextCommand}} Raft commands, which are
Raft's Read Commands. Read commands are handled on Raft leader and don't
replicate to followers. Within the context of cursors, it means that cursor
position, which is moved by the next command, is stored on leader only and
might be lost on leader change. It will lead to unexpected side effects on the
raft client because from the client's point of view, the leader migration is
seamless and should be invisible. In other words, calling next on leader A will
only move cursor position on this particular raft node, so that after leader
migration, the client's next {{next()}} command will be processed on a new
leader B and will move cursor position again to the same step.
A possible solution is to change {{CursorNextCommand}} and
{{CursorHasNextCommand}} to raft's write commands, so they will be replicated
on the followers and new followers will handle the commands correctly.
was:
Metastorage's cursor commands next and hasNext is implemented using
{{CursorNextCommand}} and {{CursorHasNextCommand}} Raft commands, which are
Raft's Read Commands. Read commands are handled on Raft leader and don't
replicate to followers. Within the context of cursors, it means that cursor
position, which is moved by the next command, is stored on leader only and
might be lost on leader change. It will lead to unexpected side effects on the
raft client because from the client's point of view, the leader migration is
seamless and should be invisible. In other words, calling next on leader A will
only move cursor position on this particular raft node, so that after leader
migration, the client's next {{next()}} command will be processed on a new
leader B and will move cursor position again to the same step.
A possible solution is to change {{CursorNextCommand}} and
{{CursorHasNextCommand}} to raft's write commands, so they will be replicated
on the followers and new followers will handle the commands correctly.
> Metastorage's cursor commands next and hasNext must work correctly after Raft
> leader was changing.
> --------------------------------------------------------------------------------------------------
>
> Key: IGNITE-15222
> URL: https://issues.apache.org/jira/browse/IGNITE-15222
> Project: Ignite
> Issue Type: Bug
> Reporter: Mirza Aliev
> Assignee: Mirza Aliev
> Priority: Major
> Fix For: 3.0.0-alpha3
>
>
> Metastorage's cursor commands next and hasNext are implemented using
> {{CursorNextCommand}} and {{CursorHasNextCommand}} Raft commands, which are
> Raft's Read Commands. Read commands are handled on Raft leader and don't
> replicate to followers. Within the context of cursors, it means that cursor
> position, which is moved by the next command, is stored on leader only and
> might be lost on leader change. It will lead to unexpected side effects on
> the raft client because from the client's point of view, the leader migration
> is seamless and should be invisible. In other words, calling next on leader A
> will only move cursor position on this particular raft node, so that after
> leader migration, the client's next {{next()}} command will be processed on a
> new leader B and will move cursor position again to the same step.
> A possible solution is to change {{CursorNextCommand}} and
> {{CursorHasNextCommand}} to raft's write commands, so they will be replicated
> on the followers and new followers will handle the commands correctly.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
