You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ignite.apache.org by "Aleksandr Polovtcev (Jira)" <ji...@apache.org> on 2023/02/06 09:39:00 UTC
[jira] [Updated] (IGNITE-14691) Implement meta storage reactive cursors
[ https://issues.apache.org/jira/browse/IGNITE-14691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Aleksandr Polovtcev updated IGNITE-14691:
-----------------------------------------
Summary: Implement meta storage reactive cursors (was: Implement meta storage reactive watches.)
> Implement meta storage reactive cursors
> ---------------------------------------
>
> Key: IGNITE-14691
> URL: https://issues.apache.org/jira/browse/IGNITE-14691
> Project: Ignite
> Issue Type: Improvement
> Reporter: Alexander Lapin
> Assignee: Aleksandr Polovtcev
> Priority: Major
> Labels: iep-61, ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The current implementation of the meta storage (IGNITE-14389) implements watches as a cursor that moves over revisions index. Such cursors are reactive by nature while current implementation is significantly simplified (for the sake of development velocity) and based on simple request/response model where each call of hasNext()/next()/close() method leads to a network round trip. The next disadvantage is that request/response model implemented on the client side.
> We should design and implement reactive model that will provide at least the following:
> * Provide effective model for data exchange over the network. Effective means that
> ** only "create watch", "close watch", "range" and "close range cursor" requests should go through Raft service while the rest data could be transferred bypassing Raft protocol.
> ** responses from meta storage should be batched if possible (i.e. for watch events it is not always possible, but it is always possible for entries form requested range)
> * Provide back pressure.
> * Provide cursor management functionality on the server side instead of client.
> * On the client side cursor should correctly fetch responses from the batch.
> UPD: Since Watches now work based on Learners functionality, the above description only applies to Cursors returned by range and prefix commands.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)