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

Pavel Kovalenko commented on IGNITE-7366:
-----------------------------------------

[~xtern] I've looked at changes and seems the logic of waiting for affinity can 
be optimized.

1) I've noticed that we're interesting only for discovery events which trigger 
PME. In this case instead of synchronous waiting for exchange future, we can 
listen on it, and after exchange is done, we need to check that discovery event 
version equals to exchange future result topology version, and only in this 
case run DepRunnable clojure.

2) Minor: Please avoid comparing topology versions by reference (Use compareTo 
in all cases)

> Affinity assignment exception in service processor during multiple nodes join
> -----------------------------------------------------------------------------
>
>                 Key: IGNITE-7366
>                 URL: https://issues.apache.org/jira/browse/IGNITE-7366
>             Project: Ignite
>          Issue Type: Bug
>          Components: compute
>    Affects Versions: 2.3
>            Reporter: Ilya Kasnacheev
>            Assignee: Pavel Pereslegin
>            Priority: Major
>
> When two nodes which are deploying services join at the same time, and 
> exception is observed:
> {code}
> SEVERE: Error when executing service: null
> java.lang.IllegalStateException: Getting affinity for topology version 
> earlier than affinity is calculated [locNode=TcpDiscoveryNode 
> [id=245d4bec-0384-4808-b66d-d2340930207f..., discPort=37500, order=2, 
> intOrder=2, lastExchangeTime=1515394551283, loc=true, 
> ver=2.3.0#20171028-sha1:8add7fd5, isClient=false], grp=ignite-sys-cache, 
> topVer=AffinityTopologyVersion [topVer=3, minorTopVer=0], 
> head=AffinityTopologyVersion [topVer=4, minorTopVer=0], 
> history=[AffinityTopologyVersion [topVer=2, minorTopVer=0], 
> AffinityTopologyVersion [topVer=2, minorTopVer=1], AffinityTopologyVersion 
> [topVer=4, minorTopVer=0]]]
> at 
> org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.cachedAffinity(GridAffinityAssignmentCache.java:514)
> at 
> org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.nodes(GridAffinityAssignmentCache.java:419)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.nodesByPartition(GridCacheAffinityManager.java:220)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.primaryByPartition(GridCacheAffinityManager.java:256)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.primaryByKey(GridCacheAffinityManager.java:247)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.primaryByKey(GridCacheAffinityManager.java:271)
> at 
> org.apache.ignite.internal.processors.service.GridServiceProcessor$TopologyListener$1.run0(GridServiceProcessor.java:1771)
> at 
> org.apache.ignite.internal.processors.service.GridServiceProcessor$DepRunnable.run(GridServiceProcessor.java:1958)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> at java.lang.Thread.run(Unknown Source)
> {code}
> This may be caused by exchange merges. There are 4 nodes joining topology. 
> When nodes 3 and 4 join at the same time, exchanges for [3, 0] and [4, 0] are 
> merged. But, TopologyListener in service processor is notified about topVer 
> [3, 0], for which there is no affinity because exchange has already moved 
> forward to [4, 0].



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to