[jira] [Assigned] (IGNITE-15988) ConnectionManager can violate the message ordering contract

["Aleksandr Polovtcev (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/IGNITE-15988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Aleksandr Polovtcev reassigned IGNITE-15988:
--------------------------------------------

    Assignee: Aleksandr Polovtcev

> ConnectionManager can violate the message ordering contract
> -----------------------------------------------------------
>
>                 Key: IGNITE-15988
>                 URL: https://issues.apache.org/jira/browse/IGNITE-15988
>             Project: Ignite
>          Issue Type: Bug
>          Components: networking
>            Reporter: Aleksandr Polovtcev
>            Assignee: Aleksandr Polovtcev
>            Priority: Major
>              Labels: ignite-3
>
> {{MessagingService#send}} method defines the following contract:
> # Messages will be delivered in the same order as they were sent
> # If a message N has been successfully delivered to a member implies that all messages preceding N have also been successfully delivered.
> However, the current underlying implementation can violate this contract in a specific case. This can happen due to the following code in the {{ConnectionManager#channel}} method:
> {code:java}
> if (consistentId != null) {
>     // If consistent id is known, try looking up a channel by consistent id. There can be an outbound connection
>     // or an inbound connection associated with that consistent id.
>     NettySender channel = channels.compute(
>             consistentId,
>             (addr, sender) -> (sender == null || !sender.isOpen()) ? null : sender
>     );
>     ...
> }
> // Get an existing client or create a new one. NettyClient provides a CompletableFuture that resolves
> // when the client is ready for write operations, so previously started client, that didn't establish connection
> // or didn't perform the handhsake operaton, can be reused.
> NettyClient client = clients.compute(address, (addr, existingClient) ->
>         existingClient != null && !existingClient.failedToConnect() && !existingClient.isDisconnected()
>                 ? existingClient : connect(addr)
> );
> {code}
> Imaging the following situation, given two nodes, called node 1 and node 2:
> # Node 1 and node 2 start, nothing happens on the membership level yet.
> # Node 1 sends a message to node 2 using the {{MessagingService#send(NetworkAddress ...)}} method.
> # In the meantime node 2 discovers the node 1 and sends a message to it using the {{MessagingService#send(ClusterNode ...)}} method.
> # Node 1 sends another message to node2, this time an incoming channel, opened in step 3, will be reused. This means that the first and the second message from node 1 will be sent over two different channels, which may not obey the aforementioned contract.
> h3. Possible solution
> A possible solution might be to always check whether the {{clients}} map contains the destination address and to prefer to use its channel. 



--
This message was sent by Atlassian Jira
(v8.20.1#820001)