[
https://issues.apache.org/jira/browse/IGNITE-18772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Puchkovskiy updated IGNITE-18772:
---------------------------------------
Description:
Let's suppose node A needs to send a message to node B.
# Future returned by the call (on node A) will either complete successfully
(if the message was delivered), or it will complete exceptionally (if node B
disappeared from the topology)
# Node B will only return the response if node A is still in the topology
# All transient failures are retried automatically until the message is
delivered OR the counterpart disappeared from the topology OR the future has
been cancelled by the user. The retries are made under the hood.
# As mentioned above, the user can cancel the delivery of the message
Things that should be carefully considered:
# Nodes might have different views of the topology: 'X sees Y' might not be
symmetric
# What kinds of topologies are concerned? Should this work over physical
topology, logical one, or over any of them (on the user's discretion)?
# Should we return a {{Publisher<T>}} (or its specialization like
{{{}Mono<T>{}}}) instead of a {{CompletableFuture<T>}} (given that we want
something reactive)?
# How do we deal with non-transient failures (like an NPE) different from
failures caused by node disappearance? Do we just keep retrying until timeout
is triggered, or we crash the node if some unexpected failure occurs, or...?
was:
Let's suppose node A needs to send a message to node B.
# Future returned by the call (on node A) will either complete successfully
(if the message was delivered), or it will complete exceptionally (if node B
disappeared from the topology)
# Node B will only return the response if node A is still in the topology
# All transient failures are retried automatically until the message is
delivered OR the counterpart disappeared from the topology OR the future has
been cancelled by the user. The retries are made under the hood.
# As mentioned above, the user can cancel the delivery of the message
Things that should be carefully considered:
# Nodes might have different views of the topology: 'X sees Y' might not be
symmetric
# What kinds of topologies are concerned? Should this work over physical
topology, logical one, or over any of them (on the user's discretion)?
# Should we return a {{Publisher<T>}} (or its specialization like
{{{}Mono<T>{}}}) instead of a {{CompletableFuture<T>}} (given that we want
something reactive)?
> Design reactive network messaging
> ---------------------------------
>
> Key: IGNITE-18772
> URL: https://issues.apache.org/jira/browse/IGNITE-18772
> Project: Ignite
> Issue Type: New Feature
> Components: networking
> Reporter: Roman Puchkovskiy
> Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> Let's suppose node A needs to send a message to node B.
> # Future returned by the call (on node A) will either complete successfully
> (if the message was delivered), or it will complete exceptionally (if node B
> disappeared from the topology)
> # Node B will only return the response if node A is still in the topology
> # All transient failures are retried automatically until the message is
> delivered OR the counterpart disappeared from the topology OR the future has
> been cancelled by the user. The retries are made under the hood.
> # As mentioned above, the user can cancel the delivery of the message
> Things that should be carefully considered:
> # Nodes might have different views of the topology: 'X sees Y' might not be
> symmetric
> # What kinds of topologies are concerned? Should this work over physical
> topology, logical one, or over any of them (on the user's discretion)?
> # Should we return a {{Publisher<T>}} (or its specialization like
> {{{}Mono<T>{}}}) instead of a {{CompletableFuture<T>}} (given that we want
> something reactive)?
> # How do we deal with non-transient failures (like an NPE) different from
> failures caused by node disappearance? Do we just keep retrying until timeout
> is triggered, or we crash the node if some unexpected failure occurs, or...?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)