[
https://issues.apache.org/jira/browse/IGNITE-19059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-19059:
-----------------------------------------
Description:
Current {{VersionedValue}} implementation has the following problem: when
{{get}} and {{complete}} methods are called concurrently, it is possible that
the {{get}} future will never be completed because of a race when updating the
actual token. This can be fixed by introducing a RW lock on {{get}} and
{{complete}} operations.
However, currently this will make the implementation too hard to understand
(there are already locks for the {{update}} method and for history trimming).
Actually, current {{VersionedValue}} implementation encapsulates two
independent concepts: "incremental" updates using the {{update}} method and
publishing the results using the {{complete(long)}} method, and
{{CompletableFuture}}-like approach, when a Versioned Value is complete with
either an explicit value or an exception.
It is proposed to fix all these issues at once:
# Get rid of concurrency issues and introduce more tests.
# Split the Versioned Value implementation in two: one for each concept.
*UPD:* The scope of this ticket appeared to be much larger than intended. While
adding some internal checks to the Incremental Versioned Value I stumbled upon
a bunch of races in {{TableManager}} regarding registering {{update}} calls in
asynchronous part of the configuration listeners, which may happen after a
revision has already been applied. This lead to quite a lot of reorganising of
VersionedValue-related code.
was:
Current {{VersionedValue}} implementation has the following problem: when
{{get}} and {{complete}} methods are called concurrently, it is possible that
the {{get}} future will never be completed because of a race when updating the
actual token. This can be fixed by introducing a RW lock on {{get}} and
{{complete}} operations.
However, currently this will make the implementation too hard to understand
(there are already locks for the {{update}} method and for history trimming).
Actually, current {{VersionedValue}} implementation encapsulates two
independent concepts: "incremental" updates using the {{update}} method and
publishing the results using the {{complete(long)}} method, and
{{CompletableFuture}}-like approach, when a Versioned Value is complete with
either an explicit value or an exception.
It is proposed to fix all these issues at once:
# Get rid of concurrency issues and introduce more tests.
# Split the Versioned Value implementation in two: one for each concept.
*UPD:* The scope of this ticket appeared to be much larger than intended. While
adding some internal checks to the Incremental Versioned Value I stumbled upon
a bunch of races in {[TableManager}} regarding registering {{update}} calls in
asynchronous part of the configuration listeners, which may happen after a
revision has already been applied. This lead to quite a lot of reorganising of
VersionedValue-related code.
> Fix completion races in Versioned Value
> ---------------------------------------
>
> Key: IGNITE-19059
> URL: https://issues.apache.org/jira/browse/IGNITE-19059
> Project: Ignite
> Issue Type: Task
> Reporter: Aleksandr Polovtcev
> Assignee: Aleksandr Polovtcev
> Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Current {{VersionedValue}} implementation has the following problem: when
> {{get}} and {{complete}} methods are called concurrently, it is possible that
> the {{get}} future will never be completed because of a race when updating
> the actual token. This can be fixed by introducing a RW lock on {{get}} and
> {{complete}} operations.
> However, currently this will make the implementation too hard to understand
> (there are already locks for the {{update}} method and for history trimming).
> Actually, current {{VersionedValue}} implementation encapsulates two
> independent concepts: "incremental" updates using the {{update}} method and
> publishing the results using the {{complete(long)}} method, and
> {{CompletableFuture}}-like approach, when a Versioned Value is complete with
> either an explicit value or an exception.
> It is proposed to fix all these issues at once:
> # Get rid of concurrency issues and introduce more tests.
> # Split the Versioned Value implementation in two: one for each concept.
> *UPD:* The scope of this ticket appeared to be much larger than intended.
> While adding some internal checks to the Incremental Versioned Value I
> stumbled upon a bunch of races in {{TableManager}} regarding registering
> {{update}} calls in asynchronous part of the configuration listeners, which
> may happen after a revision has already been applied. This lead to quite a
> lot of reorganising of VersionedValue-related code.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
