[
https://issues.apache.org/jira/browse/IGNITE-12618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-12618:
-------------------------------------
Fix Version/s: 2.8.1
> Affinity cache for version of last server event can be wiped from history
> -------------------------------------------------------------------------
>
> Key: IGNITE-12618
> URL: https://issues.apache.org/jira/browse/IGNITE-12618
> Project: Ignite
> Issue Type: Bug
> Affects Versions: 2.8
> Reporter: Vyacheslav Koptilin
> Assignee: Vyacheslav Koptilin
> Priority: Major
> Fix For: 2.9, 2.8.1
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> After IGNITE-11465 implemented, there's still a corner case when we can get
> "Getting affinity for topology version earlier than affinity is calculated"
> error.
> If the whole history (not more than
> GridAffinityAssignmentCache#MAX_HIST_LINKS_SIZE entries) consists of shallow
> copies for client events, we may be not able to fetch affinity cache for last
> affinity change version.
> We need to make GridAffinityAssignmentCache#cachedAffinity work if affinity
> version no less than [last affinity change version] is passed as an argument.
> *UPDATE*
> GridAffinityProcessor#affMap and GridAffinityAssignmentCache#affCache store
> objects for every topology version (within history range). Mappings inside
> are only shallow copies of each other, but corner-case, when cluster
> experiences unlimited client / local cache topology events, will still cause
> OOM - at least two reference objects are created for each topology version.
> We can't store a fixed number of entries either. The best solution would be
> not storing instances for client events at all. This may require severe
> refactoring of affinity assignment related logic.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
