[
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 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.
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 the state
of the cursor is not replicated on followers. That means that in the case of
changing a leader in raft group, cursor next and hasNext will work incorrectly.
For example, we called the next command on a leader twice, and after that
leader was changed, the new leader on command next returns the first element of
the cursor, which already has been returned.
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 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.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
