[JBoss JIRA] (ISPN-1706) Cannot disable the L1 Cache in some special cases
by Nicolas Filotto (JIRA)
Nicolas Filotto created ISPN-1706:
-------------------------------------
Summary: Cannot disable the L1 Cache in some special cases
Key: ISPN-1706
URL: https://issues.jboss.org/browse/ISPN-1706
Project: Infinispan
Issue Type: Bug
Components: Core API
Affects Versions: 5.1.0.CR3
Reporter: Nicolas Filotto
Assignee: Manik Surtani
In some specific cases, if we want to define a configuration in which we disabled the L1 cache and the property onRehash, we can still face the following exception:
{code}
org.infinispan.config.ConfigurationException: Can only move entries to L1 on rehash when L1 is enabled
at org.infinispan.config.ConfigurationValidatingVisitor.visitL1Type(ConfigurationValidatingVisitor.java:99)
at org.infinispan.config.DelegatingConfigurationVisitor.visitL1Type(DelegatingConfigurationVisitor.java:183)
at org.infinispan.config.Configuration$L1Type.accept(Configuration.java:3698)
at org.infinispan.config.Configuration$ClusteringType.accept(Configuration.java:2462)
at org.infinispan.config.Configuration.accept(Configuration.java:1459)
at org.infinispan.manager.DefaultCacheManager.wireCache(DefaultCacheManager.java:655)
at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:618)
at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:514)
{code}
See below a TestCase that represents one way to face this issue:
{code}
public void testConfig()
{
GlobalConfigurationBuilder gcb = GlobalConfigurationBuilder.defaultClusteredBuilder();
ConfigurationBuilder cb = new ConfigurationBuilder();
DefaultCacheManager manager = new DefaultCacheManager(gcb.build(), cb.build());
cb = new ConfigurationBuilder();
cb.clustering().cacheMode(CacheMode.DIST_SYNC).l1().disable().disableOnRehash();
manager.defineConfiguration("testConfigCache", cb.build());
manager.getCache("testConfigCache");
}
{code}
--
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
12 years, 7 months
[JBoss JIRA] (ISPN-1689) ClassCastException due to a bug in LegacyConfigurationAdaptor.adapt
by Nicolas Filotto (Created) (JIRA)
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 {{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
12 years, 7 months