[
https://issues.apache.org/jira/browse/IGNITE-12618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-12618:
-----------------------------------------
Description:
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.
was:
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.
> 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
>
> Time Spent: 10m
> 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)
