[infinispan-issues] [JBoss JIRA] (ISPN-1689) Any call to getConsistentHashClass() set the wrong value when we use new configuration object due to the globalConfiguration that is always null

Any call to getConsistentHashClass() set the wrong value when we use new configuration object due to the globalConfiguration that is always null ------------------------------------------------------------------------------------------------------------------------------------------------ Key: ISPN-1689 URL: https://issues.jboss.org/browse/ISPN-1689 Project: Infinispan Issue Type: Bug Components: Core API Affects Versions: 5.1.0.CR2 Reporter: Nicolas Filotto Assignee: Manik Surtani Priority: Critical Since I upgraded my code to use the new configuration object I realized that the starting time was much slower, after a deeper investigation I realized that the application was stuck at {{BaseStateTransferManagerImpl.waitForJoinToComplete()}} because the latch was not released due to the following exception: {code} java.lang.ClassCastException: org.infinispan.remoting.transport.jgroups.JGroupsAddress cannot be cast to org.infinispan.remoting.transport.TopologyAwareAddress at org.infinispan.distribution.ch.TopologyAwareConsistentHash.setCaches(TopologyAwareConsistentHash.java:79) at org.infinispan.distribution.ch.ConsistentHashHelper.createConsistentHash(ConsistentHashHelper.java:114) at org.infinispan.statetransfer.ReplicatedStateTransferManagerImpl.createConsistentHash(ReplicatedStateTransferManagerImpl.java:56) at org.infinispan.statetransfer.BaseStateTransferManagerImpl.prepareView(BaseStateTransferManagerImpl.java:310) at org.infinispan.cacheviews.CacheViewsManagerImpl.handlePrepareView(CacheViewsManagerImpl.java:463) at org.infinispan.cacheviews.CacheViewsManagerImpl.clusterPrepareView(CacheViewsManagerImpl.java:300) at org.infinispan.cacheviews.CacheViewsManagerImpl.clusterInstallView(CacheViewsManagerImpl.java:249) at org.infinispan.cacheviews.CacheViewsManagerImpl$ViewInstallationTask.call(CacheViewsManagerImpl.java:850) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:680) {code} Then I compared the old configuration with the new configuration and realized that {{org.infinispan.distribution.ch.TopologyAwareConsistentHash}} was wrongly added to my configuration as consistent hash. That is actually because when in {{LegacyConfigurationAdaptor.adapt}} we call {{legacy.getConsistentHashClass()}}, it is set to {{TopologyAwareConsistentHash}} because {{globalConfiguration}} and {{consistentHashClass}} are both null, see below the related code: {code} public String getConsistentHashClass() { if (clustering.hash.consistentHashClass == null) { clustering.hash.consistentHashClass = globalConfiguration == null || globalConfiguration.hasTopologyInfo() ? TopologyAwareConsistentHash.class.getName() : DefaultConsistentHash.class.getName(); } return clustering.hash.consistentHashClass; } {code} In other words any call to {{getConsistentHashClass()}} set the value of {{consistentHashClass}} to {{TopologyAwareConsistentHash}} if it has not been set and unfortunately {{DistributionManagerImpl.start()}} calls it indirectly.