[
https://issues.apache.org/jira/browse/IGNITE-18859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-18859:
-------------------------------------
Summary: PendingComparableValuesTracker extension in order to support
multiple idependent waiters assosiated with values (was:
PartitionReplicaListener extension in order to support multiple idependent
waiters assosiated with values)
> PendingComparableValuesTracker extension in order to support multiple
> idependent waiters assosiated with values
> ---------------------------------------------------------------------------------------------------------------
>
> Key: IGNITE-18859
> URL: https://issues.apache.org/jira/browse/IGNITE-18859
> Project: Ignite
> Issue Type: Improvement
> Reporter: Vladislav Pyatkov
> Assignee: Alexander Lapin
> Priority: Major
> Labels: ignite-3
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> h3. Motivation
> In order to implement placement driver API that will add an ability to await
> and get primary replicas in seems reasonable to reuse
> PendingComparableValuesTracker just because given class provides most of
> required functionality.
> {code:java}
> /**
> * Tracker that stores comparable value internally, this value can grow when
> {@link #update(Comparable)} method is called. The tracker gives
> * ability to wait for certain value, see {@link #waitFor(Comparable)}.
> */
> public class PendingComparableValuesTracker<T extends Comparable<T>>
> implements ManuallyCloseable { {code}
> However some upgrades are needed - see the definition of done section.
> h3. Definition of done
> * It's required to have an ability to complete pending waiter with specific
> value propagated to an PendingComparableValuesTracker#update() method.
> * It's required to support multiple independent waiters associated with same
> waiter key.
> h3. Implementation notes
> It make sense to extend PendingComparableValuesTracker with a new class that
> will store multiple independent waiters instead of single one, in other words
> {code:java}
> private final ConcurrentSkipListMap<T, Set<CompletableFuture<R>>>
> valueFutures = new ConcurrentSkipListMap<>(); {code}
> instead of
> {code:java}
> private final ConcurrentSkipListMap<T, CompletableFuture<R>> valueFutures =
> new ConcurrentSkipListMap<>();{code}
> In addition to that it makes sense to overload
> {code:java}
> public void update(T newValue) {code}
> with
> {code:java}
> public void update(T newValue, @Nullable R futureResult) {code}
> in order to retrieve CompletableFuture<R> from
> PendingComparableValuesTracker#waitFor() instead of CompletableFuture<Void>.
> Of course it's valid to have Void as R.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
