ignite-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexei Scherbakov (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (IGNITE-11465) Multiple client leave/join events may wipe affinity assignment history and cause transactions fail
Date Mon, 04 Mar 2019 08:26:00 GMT

    [ https://issues.apache.org/jira/browse/IGNITE-11465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16783099#comment-16783099
] 

Alexei Scherbakov commented on IGNITE-11465:
--------------------------------------------

[~ivan.glukos],

I consider changing default value to 50 risky because we still can have history overflow due
to massive not batched dynamic cache operations. Backward compatibility could be broken as
well in such scenarios.

Default value looks OK especially after IGNITE-10920 optimization.

Otherwise looks good.

> 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
>
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> 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)

Mime
View raw message