[infinispan-issues] [JBoss JIRA] (ISPN-2376) KeyAffinityServiceImpl.getKeyForAddress() seems to loop forever when DefaultConsistentHash is created for the non-local node owner

[Dan Berindei (JIRA)]

    [ https://issues.jboss.org/browse/ISPN-2376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12725253#comment-12725253 ] 

Dan Berindei commented on ISPN-2376:
------------------------------------

Scott, the DefaultConsistentHash reflects the state of the cache at the time it was created (more or less). In your case there was one existing member, node-1, and node-0 received the existing consistent hash during startup.

Before startup was over, though, it should have received another DCH that had both node-1 and node-0 as members. If it didn't, getCache() should have failed with an exception in {{StateTransferManagerImpl.waitForInitialStateTransferToComplete()}}.

So I'm sure what you mean by "DefaultConsistentHash is created for the non-local node owner" - by the time getCache() returns and you're able to create a KeyAffinityService for it, the current DCH should have both nodes in the owners list. Can you post a link to your test code?
                
> KeyAffinityServiceImpl.getKeyForAddress() seems to loop forever when DefaultConsistentHash is created for the non-local node owner
> ----------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: ISPN-2376
>                 URL: https://issues.jboss.org/browse/ISPN-2376
>             Project: Infinispan
>          Issue Type: Feature Request
>          Components: Core API
>    Affects Versions: 5.2.0.Beta1
>            Reporter: Scott Marlow
>            Assignee: Mircea Markus
>             Fix For: 5.2.0.CR1
>
>
> I instrumented KeyAffinityServiceImpl and DefaultConsistentHash to show why KeyAffinityServiceImpl is looping forever when running the AS7 clustered tests with some recent changes that aren't committed yet.  We are hoping to get through this failure so we can get clustered tests running again more completely on our continuous test server (lightning).
> We have two nodes running in the AS cluster, node-0/web and node-1/web.  
> In my recent test run, I stopped the test after it was stuck for a while.  Below is some of the instrumented logging output.
> {quote}
> KeyAffinityServiceImpl interestedInAddress() check, for address: node-1/web, filter.contains(address) returns false, filter contents [node-0/web]
> .
> .
> .
> KeyAffinityServiceImpl.getKeyForAddress() loop # 1455775 will loop again since result is null, queue [], address node-0/web
> {quote}
> We are using address "node-1/web" because that is passed into the DefaultConsistentHash constructor segmentOwners parameter (element zero). 
> Later, address=node-1/web is the primary owner of the consistent hash (hash=DefaultConsistentHash{numSegments=1, numOwners=2, members=[node-1/web, node-0/web], segmentOwners={0: 0 1}).
> I'm still collecting information and want to get a little more.  
> Let me know if there is anything that you would like to see.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira