Bug 879289 - org.infinispan.distribution.ch.DefaultConsistentHash cannot be cast to org.infinispan.distribution.ch.ReplicatedConsistentHash
Summary: org.infinispan.distribution.ch.DefaultConsistentHash cannot be cast to org.in...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: JBoss Data Grid 6
Classification: JBoss
Component: Infinispan
Version: 6.1.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ER5
: 6.1.0
Assignee: Tristan Tarrant
QA Contact: Martin Gencur
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-11-22 14:41 UTC by Anna Manukyan
Modified: 2012-11-28 14:28 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-11-28 14:28:57 UTC
Type: Bug


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker ISPN-2540 0 Major Resolved org.infinispan.distribution.ch.DefaultConsistentHash cannot be cast to org.infinispan.distribution.ch.ReplicatedConsiste... 2016-01-19 10:31:44 UTC

Comment 1 JBoss JIRA Server 2012-11-26 10:23:39 UTC
Adrian Nistor <anistor> made a comment on jira ISPN-2540

Hi Anna. Could you please post your cache configuration?

Comment 2 JBoss JIRA Server 2012-11-26 13:00:55 UTC
Anna Manukyan <amanukya> made a comment on jira ISPN-2540

Hi Adrian,

my cache configuration is:

{code}
      GlobalConfiguration glob = new GlobalConfigurationBuilder()
            .globalJmxStatistics().jmxDomain("AsyncNotifExecutorCache").allowDuplicateDomains(true)
            .transport().addProperty("configurationFile", "jgroups-tcp.xml").
                  distributedSyncTimeout(150000).
                  strictPeerToPeer(false).
                  transport(new JGroupsTransport()).
                  asyncListenerExecutor().addProperty("maxThreads", "5").
                  build();
      ConfigurationBuilder c = new ConfigurationBuilder();
      c.clustering().cacheMode(CacheMode.INVALIDATION_SYNC);

      Configuration cnf = c.build();
      DefaultCacheManager manager = new DefaultCacheManager(glob);
      manager.defineConfiguration("testCache", cnf);
{code}

Best regards,
Anna.

Comment 3 JBoss JIRA Server 2012-11-26 23:58:59 UTC
Adrian Nistor <anistor> made a comment on jira ISPN-2540

Is it possible that you are unintentionally mixing in the same cluster some nodes that are INVALIDATION_SYNC and DIST_SYNC?

Comment 4 Anna Manukyan 2012-11-27 12:12:42 UTC
Hi Adrian,

thanks for the hint. 

I guess yes, and the reason is that the cache is not properly stopped during tomcat container undeploy, and the DIST_ASYNC cache from the previous test affects the new Invalidation cache.

I run the test separately, and it doesn't fail. As well as the tests doesn't fail for EAP.

I'll try to resolve this issue.

Best regards,
Anna.

Comment 5 Tristan Tarrant 2012-11-28 10:04:15 UTC
Should this be marked invalid then ?

Comment 6 Anna Manukyan 2012-11-28 10:06:28 UTC
I guess yes.

As soon as I'll fix the test on my side, and make sure that it doesn't fail, I'll mark the bug as invalid.

Comment 7 JBoss JIRA Server 2012-11-28 14:26:16 UTC
Anna Manukyan <amanukya> updated the status of jira ISPN-2540 to Resolved

Comment 8 JBoss JIRA Server 2012-11-28 14:26:16 UTC
Anna Manukyan <amanukya> made a comment on jira ISPN-2540

The problem was in the unsuccessfull undeployment of tomcat container, which caused that the DIST_ASYNC cache created in one test, was harming the INVALIDATION test in another.

The tests are fixed.


Note You need to log in before you can comment on or make changes to this bug.