[JBoss JIRA] (ISPN-3035) Members can re-appear by itself in the consistent hash after leaving
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-3035?page=com.atlassian.jira.plugin.... ]
Dan Berindei reassigned ISPN-3035:
----------------------------------
Assignee: Dan Berindei (was: Mircea Markus)
> Members can re-appear by itself in the consistent hash after leaving
> --------------------------------------------------------------------
>
> Key: ISPN-3035
> URL: https://issues.jboss.org/browse/ISPN-3035
> Project: Infinispan
> Issue Type: Bug
> Components: State transfer
> Affects Versions: 5.2.5.Final, 5.3.0.Alpha1
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 5.3.0.Beta1
>
> Attachments: dret.log
>
>
> Seen as an intermittent failure in DataRehashedEventTest:
> {noformat}
> 2013-04-23 14:07:45,459 DEBUG (testng-DataRehashedEventTest) [org.infinispan.manager.DefaultCacheManager] Stopping cache manager ISPN on NodeC-58711
> 2013-04-23 14:07:45,468 INFO (testng-DataRehashedEventTest) [org.infinispan.remoting.transport.jgroups.JGroupsTransport] ISPN000080: Disconnecting and closing JGroups Channel
> 2013-04-23 14:07:46,469 DEBUG (testng-DataRehashedEventTest) [org.jgroups.protocols.pbcast.GMS] NodeC-58711: sending LEAVE request to NodeA-28008
> 2013-04-23 14:07:46,489 DEBUG (Incoming-2,ISPN,NodeA-28008) [org.jgroups.protocols.pbcast.GMS] NodeA-28008: installing [NodeA-28008|4] [NodeA-28008, NodeB-46156, NodeC-58711]
> 2013-04-23 14:07:46,491 DEBUG (asyncTransportThread-0,NodeA) [org.infinispan.topology.ClusterTopologyManagerImpl] Starting cluster-wide rebalance for cache ___defaultcache, topology = CacheTopology{id=8, currentCH=DefaultConsistentHash{numSegments=60, numOwners=2, members=[NodeA-28008, NodeB-46156]}, pendingCH=DefaultConsistentHash{numSegments=60, numOwners=2, members=[NodeA-28008, NodeB-46156, NodeC-58711]}}
> 2013-04-23 14:07:49,493 ERROR (testng-DataRehashedEventTest) [org.infinispan.test.fwk.UnitTestTestNGListener] Test testJoinAndLeave(org.infinispan.statetransfer.DataRehashedEventTest) failed.
> java.lang.AssertionError: expected [2] but found [6]
> at org.testng.Assert.fail(Assert.java:94)
> at org.testng.Assert.failNotEquals(Assert.java:494)
> at org.testng.Assert.assertEquals(Assert.java:123)
> at org.testng.Assert.assertEquals(Assert.java:370)
> at org.testng.Assert.assertEquals(Assert.java:380)
> at org.infinispan.statetransfer.DataRehashedEventTest.testJoinAndLeave(DataRehashedEventTest.java:114)
> {noformat}
> The initial cluster has 3 nodes: A, B, C. C is killed, but somehow remains in the ClusterCacheStatus on the coordinator.
> Then C re-appears in the JGroups view (possibly a JGroups issue). The problem in Infinispan is that the coordinator now sees C as a joiner, and it rebalances the cache to include C in the consistent hash again.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 1 month
[JBoss JIRA] (ISPN-3035) Members can re-appear by itself in the consistent hash after leaving
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-3035?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-3035:
-------------------------------
Attachment: dret.log
Attached DEBUG-only log file.
> Members can re-appear by itself in the consistent hash after leaving
> --------------------------------------------------------------------
>
> Key: ISPN-3035
> URL: https://issues.jboss.org/browse/ISPN-3035
> Project: Infinispan
> Issue Type: Bug
> Components: State transfer
> Affects Versions: 5.2.5.Final, 5.3.0.Alpha1
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 5.3.0.Beta1
>
> Attachments: dret.log
>
>
> Seen as an intermittent failure in DataRehashedEventTest:
> {noformat}
> 2013-04-23 14:07:45,459 DEBUG (testng-DataRehashedEventTest) [org.infinispan.manager.DefaultCacheManager] Stopping cache manager ISPN on NodeC-58711
> 2013-04-23 14:07:45,468 INFO (testng-DataRehashedEventTest) [org.infinispan.remoting.transport.jgroups.JGroupsTransport] ISPN000080: Disconnecting and closing JGroups Channel
> 2013-04-23 14:07:46,469 DEBUG (testng-DataRehashedEventTest) [org.jgroups.protocols.pbcast.GMS] NodeC-58711: sending LEAVE request to NodeA-28008
> 2013-04-23 14:07:46,489 DEBUG (Incoming-2,ISPN,NodeA-28008) [org.jgroups.protocols.pbcast.GMS] NodeA-28008: installing [NodeA-28008|4] [NodeA-28008, NodeB-46156, NodeC-58711]
> 2013-04-23 14:07:46,491 DEBUG (asyncTransportThread-0,NodeA) [org.infinispan.topology.ClusterTopologyManagerImpl] Starting cluster-wide rebalance for cache ___defaultcache, topology = CacheTopology{id=8, currentCH=DefaultConsistentHash{numSegments=60, numOwners=2, members=[NodeA-28008, NodeB-46156]}, pendingCH=DefaultConsistentHash{numSegments=60, numOwners=2, members=[NodeA-28008, NodeB-46156, NodeC-58711]}}
> 2013-04-23 14:07:49,493 ERROR (testng-DataRehashedEventTest) [org.infinispan.test.fwk.UnitTestTestNGListener] Test testJoinAndLeave(org.infinispan.statetransfer.DataRehashedEventTest) failed.
> java.lang.AssertionError: expected [2] but found [6]
> at org.testng.Assert.fail(Assert.java:94)
> at org.testng.Assert.failNotEquals(Assert.java:494)
> at org.testng.Assert.assertEquals(Assert.java:123)
> at org.testng.Assert.assertEquals(Assert.java:370)
> at org.testng.Assert.assertEquals(Assert.java:380)
> at org.infinispan.statetransfer.DataRehashedEventTest.testJoinAndLeave(DataRehashedEventTest.java:114)
> {noformat}
> The initial cluster has 3 nodes: A, B, C. C is killed, but somehow remains in the ClusterCacheStatus on the coordinator.
> Then C re-appears in the JGroups view (possibly a JGroups issue). The problem in Infinispan is that the coordinator now sees C as a joiner, and it rebalances the cache to include C in the consistent hash again.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 1 month
[JBoss JIRA] (ISPN-3035) Members can re-appear by itself in the consistent hash after leaving
by Dan Berindei (JIRA)
Dan Berindei created ISPN-3035:
----------------------------------
Summary: Members can re-appear by itself in the consistent hash after leaving
Key: ISPN-3035
URL: https://issues.jboss.org/browse/ISPN-3035
Project: Infinispan
Issue Type: Bug
Components: State transfer
Reporter: Dan Berindei
Assignee: Mircea Markus
Noticed as an intermittent failure in DataRehashedEventTest:
{noformat}
2013-04-23 14:07:45,459 DEBUG (testng-DataRehashedEventTest) [org.infinispan.manager.DefaultCacheManager] Stopping cache manager ISPN on NodeC-58711
2013-04-23 14:07:45,468 INFO (testng-DataRehashedEventTest) [org.infinispan.remoting.transport.jgroups.JGroupsTransport] ISPN000080: Disconnecting and closing JGroups Channel
2013-04-23 14:07:46,469 DEBUG (testng-DataRehashedEventTest) [org.jgroups.protocols.pbcast.GMS] NodeC-58711: sending LEAVE request to NodeA-28008
2013-04-23 14:07:46,489 DEBUG (Incoming-2,ISPN,NodeA-28008) [org.jgroups.protocols.pbcast.GMS] NodeA-28008: installing [NodeA-28008|4] [NodeA-28008, NodeB-46156, NodeC-58711]
2013-04-23 14:07:46,491 DEBUG (asyncTransportThread-0,NodeA) [org.infinispan.topology.ClusterTopologyManagerImpl] Starting cluster-wide rebalance for cache ___defaultcache, topology = CacheTopology{id=8, currentCH=DefaultConsistentHash{numSegments=60, numOwners=2, members=[NodeA-28008, NodeB-46156]}, pendingCH=DefaultConsistentHash{numSegments=60, numOwners=2, members=[NodeA-28008, NodeB-46156, NodeC-58711]}}
2013-04-23 14:07:49,493 ERROR (testng-DataRehashedEventTest) [org.infinispan.test.fwk.UnitTestTestNGListener] Test testJoinAndLeave(org.infinispan.statetransfer.DataRehashedEventTest) failed.
java.lang.AssertionError: expected [2] but found [6]
at org.testng.Assert.fail(Assert.java:94)
at org.testng.Assert.failNotEquals(Assert.java:494)
at org.testng.Assert.assertEquals(Assert.java:123)
at org.testng.Assert.assertEquals(Assert.java:370)
at org.testng.Assert.assertEquals(Assert.java:380)
at org.infinispan.statetransfer.DataRehashedEventTest.testJoinAndLeave(DataRehashedEventTest.java:114)
{noformat}
The initial cluster has 3 nodes: A, B, C. C is killed, but somehow remains in the ClusterCacheStatus on the coordinator.
Then C re-appears in the JGroups view (possibly a JGroups issue). The problem in Infinispan is that the coordinator now sees C as a joiner, and it rebalances the cache to include C in the consistent hash again.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 1 month
[JBoss JIRA] (ISPN-2957) CustomInterceptor configuration is incomplete and buggy
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-2957?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-2957:
-------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> CustomInterceptor configuration is incomplete and buggy
> -------------------------------------------------------
>
> Key: ISPN-2957
> URL: https://issues.jboss.org/browse/ISPN-2957
> Project: Infinispan
> Issue Type: Bug
> Components: Configuration, Core API
> Affects Versions: 5.2.1.Final
> Reporter: Alan STS
> Assignee: Tristan Tarrant
> Fix For: 5.3.0.Final
>
>
> Infinispan 5.2 schema allows to declare a custom interceptor with properties as follows:
> <customInterceptors>
> <interceptor position="LAST" class="com.group.awms.is.resource.dao.infinispan.interceptor.ApplicationInterceptor">
> <properties>
> <property name="cacheActivityName" value="activity" />
> </properties>
> </interceptor>
> </customInterceptors>
> Problem is that method parseInterceptor of class Parser52 does not expect any content for interceptors and the following exception is raised:
> Message: Unexpected element '{urn:infinispan:config:5.2}properties' encountered
> at org.infinispan.configuration.parsing.ParseUtils.unexpectedElement(ParseUtils.java:57)
> at org.infinispan.configuration.parsing.ParseUtils.requireNoContent(ParseUtils.java:152)
> at org.infinispan.configuration.parsing.Parser52.parseInterceptor(Parser52.java:1186)
> at org.infinispan.configuration.parsing.Parser52.parseCustomInterceptors(Parser52.java:1148)
> at org.infinispan.configuration.parsing.Parser52.parseCache(Parser52.java:156)
> at org.infinispan.configuration.parsing.Parser52.parseNamedCache(Parser52.java:139)
> at org.infinispan.configuration.parsing.Parser52.readElement(Parser52.java:106)
> at org.infinispan.configuration.parsing.Parser52.readElement(Parser52.java:75)
> at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110)
> at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69)
> at org.infinispan.configuration.parsing.ParserRegistry.parse(ParserRegistry.java:77)
> ... 40 more
> The Parser class is not in sync with the schema.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 1 month
[JBoss JIRA] (ISPN-2957) CustomInterceptor configuration is incomplete and buggy
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-2957?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-2957:
----------------------------------
Status: Pull Request Sent (was: Reopened)
Git Pull Request: https://github.com/infinispan/infinispan/pull/1773, https://github.com/infinispan/infinispan/pull/1779 (was: https://github.com/infinispan/infinispan/pull/1773)
> CustomInterceptor configuration is incomplete and buggy
> -------------------------------------------------------
>
> Key: ISPN-2957
> URL: https://issues.jboss.org/browse/ISPN-2957
> Project: Infinispan
> Issue Type: Bug
> Components: Configuration, Core API
> Affects Versions: 5.2.1.Final
> Reporter: Alan STS
> Assignee: Tristan Tarrant
> Fix For: 5.3.0.Final
>
>
> Infinispan 5.2 schema allows to declare a custom interceptor with properties as follows:
> <customInterceptors>
> <interceptor position="LAST" class="com.group.awms.is.resource.dao.infinispan.interceptor.ApplicationInterceptor">
> <properties>
> <property name="cacheActivityName" value="activity" />
> </properties>
> </interceptor>
> </customInterceptors>
> Problem is that method parseInterceptor of class Parser52 does not expect any content for interceptors and the following exception is raised:
> Message: Unexpected element '{urn:infinispan:config:5.2}properties' encountered
> at org.infinispan.configuration.parsing.ParseUtils.unexpectedElement(ParseUtils.java:57)
> at org.infinispan.configuration.parsing.ParseUtils.requireNoContent(ParseUtils.java:152)
> at org.infinispan.configuration.parsing.Parser52.parseInterceptor(Parser52.java:1186)
> at org.infinispan.configuration.parsing.Parser52.parseCustomInterceptors(Parser52.java:1148)
> at org.infinispan.configuration.parsing.Parser52.parseCache(Parser52.java:156)
> at org.infinispan.configuration.parsing.Parser52.parseNamedCache(Parser52.java:139)
> at org.infinispan.configuration.parsing.Parser52.readElement(Parser52.java:106)
> at org.infinispan.configuration.parsing.Parser52.readElement(Parser52.java:75)
> at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110)
> at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69)
> at org.infinispan.configuration.parsing.ParserRegistry.parse(ParserRegistry.java:77)
> ... 40 more
> The Parser class is not in sync with the schema.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 1 month
[JBoss JIRA] (ISPN-3010) Cache GET operation retrieves a Class instance instead of expected type
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/ISPN-3010?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero updated ISPN-3010:
----------------------------------
Fix Version/s: 5.3.0.Beta1
Priority: Critical (was: Major)
> Cache GET operation retrieves a Class instance instead of expected type
> -----------------------------------------------------------------------
>
> Key: ISPN-3010
> URL: https://issues.jboss.org/browse/ISPN-3010
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.2.5.Final
> Reporter: Sanne Grinovero
> Assignee: Mircea Markus
> Priority: Critical
> Labels: stable_embedded_query
> Fix For: 5.3.0.Beta1
>
>
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/hibernate-search-mast...
> {quote}
> Error Message
> HSEARCH000103: Unable to initialize IndexManager emails
> Stacktrace
> org.hibernate.search.SearchException: HSEARCH000103: Unable to initialize IndexManager emails
> at org.hibernate.search.indexes.impl.IndexManagerHolder.createIndexManager(IndexManagerHolder.java:230)
> at org.hibernate.search.indexes.impl.IndexManagerHolder.buildEntityIndexBinding(IndexManagerHolder.java:102)
> at org.hibernate.search.spi.SearchFactoryBuilder.initDocumentBuilders(SearchFactoryBuilder.java:414)
> at org.hibernate.search.spi.SearchFactoryBuilder.buildNewSearchFactory(SearchFactoryBuilder.java:222)
> at org.hibernate.search.spi.SearchFactoryBuilder.buildSearchFactory(SearchFactoryBuilder.java:146)
> at org.hibernate.search.event.impl.FullTextIndexEventListener.initialize(FullTextIndexEventListener.java:130)
> at org.hibernate.search.hcore.impl.HibernateSearchIntegrator.integrate(HibernateSearchIntegrator.java:83)
> at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:303)
> at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1750)
> at org.hibernate.search.test.util.FullTextSessionBuilder.build(FullTextSessionBuilder.java:182)
> at org.hibernate.search.infinispan.StoredIndexTest.startNode(StoredIndexTest.java:121)
> at org.hibernate.search.infinispan.StoredIndexTest.testRestartingNode(StoredIndexTest.java:53)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
> at org.junit.runners.BlockJUnit4ClassRunner.runNotIgnored(BlockJUnit4ClassRunner.java:79)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:71)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:49)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:236)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:134)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:113)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
> at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
> at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:103)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)
> Caused by: java.lang.ClassCastException: java.lang.Class cannot be cast to [B
> at org.infinispan.lucene.SingleChunkIndexInput.<init>(SingleChunkIndexInput.java:49)
> at org.infinispan.lucene.InfinispanDirectory.openInput(InfinispanDirectory.java:290)
> at org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:620)
> at org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:554)
> at org.apache.lucene.index.SegmentInfos.read(SegmentInfos.java:359)
> at org.apache.lucene.index.IndexReader.indexExists(IndexReader.java:1099)
> at org.hibernate.search.store.impl.DirectoryProviderHelper.initializeIndexIfNeeded(DirectoryProviderHelper.java:155)
> at org.hibernate.search.infinispan.impl.InfinispanDirectoryProvider.start(InfinispanDirectoryProvider.java:103)
> at org.hibernate.search.indexes.impl.DirectoryBasedIndexManager.initialize(DirectoryBasedIndexManager.java:104)
> at org.hibernate.search.indexes.impl.IndexManagerHolder.createIndexManager(IndexManagerHolder.java:227)
> ... 42 more
> {quote}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 1 month