[
https://issues.apache.org/jira/browse/IGNITE-11465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Rakov updated IGNITE-11465:
--------------------------------
Description:
We keep history of GridAffinityAssignmentCache#MAX_HIST_SIZE affinity
assignments. However, flood of client joins/leaves may wipe it out entirely and
cause fail/hang of transaction that was started before the flood due to the
following exception:
{code:java}
if (cache == null || cache.topologyVersion().compareTo(topVer) > 0)
{
throw new IllegalStateException("Getting affinity for topology
version earlier than affinity is " +
"calculated [locNode=" + ctx.discovery().localNode() +
", grp=" + cacheOrGrpName +
", topVer=" + topVer +
", head=" + head.get().topologyVersion() +
", history=" + affCache.keySet() +
']');
}
{code}
History is limited in order to prevent JVM heap overflow. At the same time,
only "server event" affinity assignments are heavy: "client event" assignments
are just shallow copies of "server event" assignments.
I suggest to limit history by the number of "server event" assignments.
Also, considering the provided fix, I don't see any need to keep 500 items in
history. I propose to change history size to 50.
was:
We keep history of GridAffinityAssignmentCache#MAX_HIST_SIZE affinity
assignments. However, flood of client joins/leaves may wipe it out entirely and
cause fail/hang of transaction that was started before the flood due to the
following exception:
{code:java}
if (cache == null || cache.topologyVersion().compareTo(topVer) > 0)
{
throw new IllegalStateException("Getting affinity for topology
version earlier than affinity is " +
"calculated [locNode=" + ctx.discovery().localNode() +
", grp=" + cacheOrGrpName +
", topVer=" + topVer +
", head=" + head.get().topologyVersion() +
", history=" + affCache.keySet() +
']');
}
{code}
History is limited in order to prevent JVM heap overflow. At the same time,
only "server event" affinity assignments are heavy: "client event" assignments
are just shallow copies of "server event" assignments.
I suggest to limit history by the number of "server event" assignments.
Also, considering the provided fix, I don't see any need to keep 500 items in
history. I changed history size to 40.
> Multiple client leave/join events may wipe affinity assignment history and
> cause transactions fail
> --------------------------------------------------------------------------------------------------
>
> Key: IGNITE-11465
> URL: https://issues.apache.org/jira/browse/IGNITE-11465
> Project: Ignite
> Issue Type: Bug
> Reporter: Ivan Rakov
> Assignee: Ivan Rakov
> Priority: Major
> Fix For: 2.8
>
>
> We keep history of GridAffinityAssignmentCache#MAX_HIST_SIZE affinity
> assignments. However, flood of client joins/leaves may wipe it out entirely
> and cause fail/hang of transaction that was started before the flood due to
> the following exception:
> {code:java}
> if (cache == null || cache.topologyVersion().compareTo(topVer) >
> 0) {
> throw new IllegalStateException("Getting affinity for
> topology version earlier than affinity is " +
> "calculated [locNode=" + ctx.discovery().localNode() +
> ", grp=" + cacheOrGrpName +
> ", topVer=" + topVer +
> ", head=" + head.get().topologyVersion() +
> ", history=" + affCache.keySet() +
> ']');
> }
> {code}
> History is limited in order to prevent JVM heap overflow. At the same time,
> only "server event" affinity assignments are heavy: "client event"
> assignments are just shallow copies of "server event" assignments.
> I suggest to limit history by the number of "server event" assignments.
> Also, considering the provided fix, I don't see any need to keep 500 items in
> history. I propose to change history size to 50.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
