[
https://issues.jboss.org/browse/ISPN-1689?page=com.atlassian.jira.plugin....
]
Nicolas Filotto updated ISPN-1689:
----------------------------------
Description:
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.
was:
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
{{TopologyAwareConsistentHash}} if it has not been set and unfortunately
{{DistributionManagerImpl.start()}} calls it indirectly.
Git Pull Request:
https://github.com/infinispan/infinispan/pull/787/files (was:
https://github.com/infinispan/infinispan/pull/787/files)
ClassCastException due to a bug in LegacyConfigurationAdaptor.adapt
-------------------------------------------------------------------
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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see:
http://www.atlassian.com/software/jira