Hi Scott<br><br><div class="gmail_quote">On Wed, Oct 10, 2012 at 6:20 AM, Scott Marlow <span dir="ltr">&lt;<a href="mailto:smarlow@redhat.com" target="_blank">smarlow@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I&#39;m trying to understand more about whether it makes sense for a<br>
DefaultConsistentHash to be created with a non-local owner specified in<br>
the DefaultConsistentHash constructor &quot;segmentOwners&quot; parameter.<br>
<br></blockquote><div><br>It definitely makes sense for such a DefaultConsistentHash to exist while the cache is starting. But by the time the cache has started (i.e. getCache() has returned), it should have been replaced with a DefaultConsistentHash that contains the local node as well.<br>
<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
During some AS7 cluster testing that I&#39;m running on my machine, I&#39;m<br>
seeing the test stall because we loop endlessly in<br>
KeyAffinityServiceImpl.getKeyForAddress().  We loop because<br>
KeyAffinityServiceImpl.generateKeys() doesn&#39;t add any keys.<br>
<br>
We don&#39;t generate any keys because<br>
DefaultConsistentHash.locatePrimaryOwnerForSegment() returns address<br>
&quot;node-1/web&quot; which never matches the local nodes filter<br>
(KeyAffinityServiceImpl.interestedInAddress() only filters for local<br>
owners via &quot;node-0/web&quot;).<br>
<br>
<a href="http://pastie.org/5027574" target="_blank">http://pastie.org/5027574</a> shows the call stack for the<br>
DefaultConsistentHash constructor that is the same instance that is used<br>
above.  If you look at the call stack, it looks like the<br>
DefaultConsistentHash instance may of being serialized on the other node<br>
and sent over (which would explain why its owner is &quot;node-1/web&quot; but<br>
still not sure why/how it comes into play with local<br>
KeyAffinityServiceImpl.generateKeys()).<br>
<br></blockquote><div><br>My guess is you&#39;re able to access the cache before it has finished starting, and the KeyAffinityService doesn&#39;t know how to deal with a cache that doesn&#39;t have any local state yet. Again, this should not happen - getCache() should not return that soon - but it could be that it does happen when multiple threads try to start the same cache in parallel. Can you post logs with TRACE enabled for org.infinispan and/or a link to your test code?<br>
<br>Cheers<br>Dan<br> <br></div></div>