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.
UPD: Since Watches now work based on Learners functionality, the above description only applies to Cursors returned by range and prefix commands.
Attachments
Issue Links
- causes
-
IGNITE-18735 Extract Meta Storage Publisher thread pool size into Configuration
-
- Open
-
- is related to
-
IGNITE-18397 Rework Watches based on learners
-
- Resolved
-
- links to
