[
https://issues.apache.org/jira/browse/IGNITE-14691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey N. Gura updated IGNITE-14691:
------------------------------------
Description:
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.
was:to be provided by [~agura]
> Implement meta storage reactive watches.
> ----------------------------------------
>
> Key: IGNITE-14691
> URL: https://issues.apache.org/jira/browse/IGNITE-14691
> Project: Ignite
> Issue Type: Improvement
> Reporter: Alexander Lapin
> Priority: Major
> Labels: iep-61, ignite-3
>
> 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.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
