[
https://issues.apache.org/jira/browse/IGNITE-29100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Davydov updated IGNITE-29100:
------------------------------------
Description:
In a cluster that spans data centers, some operations take several round trips
between data centers, and some of the timeouts that bound them have defaults
that are too short for that. The Multi Data Center page doesn't say which
timeouts to review.
The most visible one is TcpDiscoverySpi.networkTimeout (5000 ms by default). A
joining node waits that long for its join to complete. The join passes the
whole discovery ring, so with a long round trip the wait can run out: the node
logs "will repeat join process" and joins again, while the rest of the cluster
may already wait for it in partition map exchange. This setting is separate
from IgniteConfiguration.networkTimeout, which discovery does not read.
This adds a section to the Multi Data Center page. For each timeout worth
reviewing it says what the timeout bounds in such a cluster, its default, what
goes wrong when it is too low, and when to raise it. A timeout whose default
already covers the cross data center case is not listed.
The list comes from two checks: the multi data center ducktests run at 100 ms
of cross data center latency with each of their timeout overrides set back to
Ignite's default, and the code of the timeouts the tests don't override.
was:
In a cluster that spans data centers, a joining node waits for its join to
complete for `TcpDiscoverySpi.networkTimeout` (5 seconds by default). The join
has to pass the whole discovery ring, so with a long round trip between data
centers it can take longer, and the node then repeats its join while the rest
of the cluster is already waiting for it in partition map exchange.
The setting is separate from `IgniteConfiguration.networkTimeout`, and the
documentation does not say so. This adds a note to the Multi Data Center page
and clarifies the `networkTimeout` row of the discovery properties table.
> Document the timeouts to tune for multi data center deployments
> ---------------------------------------------------------------
>
> Key: IGNITE-29100
> URL: https://issues.apache.org/jira/browse/IGNITE-29100
> Project: Ignite
> Issue Type: Task
> Reporter: Maksim Davydov
> Assignee: Maksim Davydov
> Priority: Minor
> Labels: IEP-140, ise
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In a cluster that spans data centers, some operations take several round
> trips between data centers, and some of the timeouts that bound them have
> defaults that are too short for that. The Multi Data Center page doesn't say
> which timeouts to review.
> The most visible one is TcpDiscoverySpi.networkTimeout (5000 ms by default).
> A joining node waits that long for its join to complete. The join passes the
> whole discovery ring, so with a long round trip the wait can run out: the
> node logs "will repeat join process" and joins again, while the rest of the
> cluster may already wait for it in partition map exchange. This setting is
> separate from IgniteConfiguration.networkTimeout, which discovery does not
> read.
> This adds a section to the Multi Data Center page. For each timeout worth
> reviewing it says what the timeout bounds in such a cluster, its default,
> what goes wrong when it is too low, and when to raise it. A timeout whose
> default already covers the cross data center case is not listed.
> The list comes from two checks: the multi data center ducktests run at 100 ms
> of cross data center latency with each of their timeout overrides set back to
> Ignite's default, and the code of the timeouts the tests don't override.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
