[
https://issues.apache.org/jira/browse/IGNITE-9558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16612152#comment-16612152
]
Ilya Lantukh commented on IGNITE-9558:
--------------------------------------
It looks like special handling for near caches isn't required.
Also, it should be theoretically possible to make similar optimizations for
join/leave events of server nodes that are not in baseline.
> Avoid changing AffinityTopologyVersion on client connect when possible
> ----------------------------------------------------------------------
>
> Key: IGNITE-9558
> URL: https://issues.apache.org/jira/browse/IGNITE-9558
> Project: Ignite
> Issue Type: Improvement
> Affects Versions: 2.0
> Reporter: Alexey Goncharuk
> Assignee: Ilya Lantukh
> Priority: Major
>
> Currently a client join event changes discovery topology version which, in
> turn, changes AffinityTopologyVersion.
> When a client maps transaction on new AffinityTopologyVersion, corresponding
> message is not processed on remote node until remote node receives the
> corresponding discovery event. If discovery event delivery is delayed for
> some reason, this will result in transaction stalls on client joins.
> Since the client node does not change partition affinity, we can safely map
> transactions on the previous topology version and do not change the affinity
> topology version at all.
> Some cases need special care and probably do not qualify for this
> optimization, such as when client has near cache or client hosts partition
> for REPLICATED cache.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
