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)