You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ignite.apache.org by "Denis Chudov (Jira)" <ji...@apache.org> on 2023/03/14 16:16:00 UTC

[jira] [Commented] (IGNITE-18763) Parallel Meta Storage Watch processing

    [ https://issues.apache.org/jira/browse/IGNITE-18763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17700290#comment-17700290 ] 

Denis Chudov commented on IGNITE-18763:
---------------------------------------

[~apolovtcev] lgtm.

> Parallel Meta Storage Watch processing
> --------------------------------------
>
>                 Key: IGNITE-18763
>                 URL: https://issues.apache.org/jira/browse/IGNITE-18763
>             Project: Ignite
>          Issue Type: Task
>          Components: persistence
>            Reporter: Sergey Chugunov
>            Assignee: Aleksandr Polovtcev
>            Priority: Major
>              Labels: ignite-3
>             Fix For: 3.0.0-beta2
>
>          Time Spent: 50m
>  Remaining Estimate: 0h
>
> Currently Meta Storage Watches follow the given contract:
> # All listeners are processed sequentially in the order that they have been registered;
> # All listeners are processed in the same thread;
> # All notifications are grouped by a particular revision. After all events for a particular revision get processed, all modified keys are persisted into the Vault.
> Some components may rely on this to ensure that dependent components can observe the most recent component state, because they registered their Meta Storage listeners after the  component they depend on, therefore it is guaranteed that that component has already processed current Meta Storage revision. 
> This approach can be improved in terms of performance by enabling concurrent Watch processing in multiple threads. In order to do that, we need to check and fix the following places:
> # If a component depends on another component's state, this state must be extracted into a Versioned Value;
> # If a component updates its state, relying on the fact, that this state is always updated in a single thread, concurrent primitives must be introduced to ensure thread safety;
> # Check if it is possible to persist updated keys in the Vault individually, thus making it possible not to wait for all Watches for a particular revision to complete before starting to process updates belonging to the next revision. 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)