May 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-3035) Members can re-appear by itself in the consistent hash after leaving

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3035?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3035: -------------------------------- Fix Version/s: 5.3.0.CR1 (was: 5.3.0.Beta2) > 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.CR1 > > Attachments: dret.log, dret2.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

12 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3028) Add tests for example configuration files

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3028?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3028: -------------------------------- Fix Version/s: 5.3.0.CR1 (was: 5.3.0.Beta2) > Add tests for example configuration files > ----------------------------------------- > > Key: ISPN-3028 > URL: https://issues.jboss.org/browse/ISPN-3028 > Project: Infinispan > Issue Type: Task > Components: Server > Affects Versions: 5.3.0.Alpha1 > Reporter: Martin Gencur > Assignee: Martin Gencur > Fix For: 5.3.0.CR1 > > -- 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

12 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3010) Cache GET operation retrieves a Class instance instead of expected type

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3010?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3010: -------------------------------- Fix Version/s: 5.3.0.CR1 (was: 5.3.0.Beta2) > 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 > Labels: stable_embedded_query > Fix For: 5.3.0.CR1 > > > 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

12 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3023) Re-implement BoundedConcurrentHashMap using CHMv8 designs

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3023?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3023: -------------------------------- Fix Version/s: 5.3.0.CR1 (was: 5.3.0.Beta2) > Re-implement BoundedConcurrentHashMap using CHMv8 designs > --------------------------------------------------------- > > Key: ISPN-3023 > URL: https://issues.jboss.org/browse/ISPN-3023 > Project: Infinispan > Issue Type: Feature Request > Components: Core API, Eviction > Affects Versions: 5.2.5.Final > Reporter: Manik Surtani > Assignee: Manik Surtani > Priority: Minor > Labels: performance > Fix For: 5.3.0.CR1, 5.3.0.Final > > > This is better than the current segment-based approach, in terms of memory footprint as well as performance under high concurrency. -- 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

12 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2999) getCacheEntry not working when distribution gets go remote

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2999?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2999: -------------------------------- Fix Version/s: 5.3.0.CR1 (was: 5.3.0.Beta2) > getCacheEntry not working when distribution gets go remote > ---------------------------------------------------------- > > Key: ISPN-2999 > URL: https://issues.jboss.org/browse/ISPN-2999 > Project: Infinispan > Issue Type: Bug > Affects Versions: 5.2.5.Final > Reporter: Galder Zamarreño > Assignee: Mircea Markus > Fix For: 5.3.0.CR1, 5.3.0.Final > > > Assuming the cache contains byte[], you get this exception when calling getCacheEntry(K) for a key not available locally: > {code}org.infinispan.server.hotrod.HotRodException: java.lang.ClassCastException: [B cannot be cast to org.infinispan.container.entries.CacheEntry > at org.infinispan.server.hotrod.HotRodDecoder.createServerException(HotRodDecoder.scala:216) > at org.infinispan.server.core.AbstractProtocolDecoder.decode(AbstractProtocolDecoder.scala:79) > at org.infinispan.server.core.AbstractProtocolDecoder.decode(AbstractProtocolDecoder.scala:49) > at org.jboss.netty.handler.codec.replay.ReplayingDecoder.callDecode(ReplayingDecoder.java:500) > at org.jboss.netty.handler.codec.replay.ReplayingDecoder.messageReceived(ReplayingDecoder.java:435) > at org.infinispan.server.core.AbstractProtocolDecoder.messageReceived(AbstractProtocolDecoder.scala:393) > at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:268) > at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:255) > at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:88) > at org.jboss.netty.channel.socket.nio.AbstractNioWorker.process(AbstractNioWorker.java:107) > at org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:313) > at org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:88) > at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:178) > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) > at java.lang.Thread.run(Thread.java:680) > Caused by: java.lang.ClassCastException: [B cannot be cast to org.infinispan.container.entries.CacheEntry > at org.infinispan.CacheImpl.getCacheEntry(CacheImpl.java:299) > at org.infinispan.CacheImpl.getCacheEntry(CacheImpl.java:304) > at org.infinispan.server.core.AbstractProtocolDecoder.get(AbstractProtocolDecoder.scala:287) > at org.infinispan.server.core.AbstractProtocolDecoder.decodeKey(AbstractProtocolDecoder.scala:117) > at org.infinispan.server.core.AbstractProtocolDecoder.decode(AbstractProtocolDecoder.scala:73) > ... 14 more{code} -- 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

12 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2995) AtomicHashMap locking issue [optimistic]

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2995?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2995: -------------------------------- Fix Version/s: 5.3.0.CR1 (was: 5.3.0.Beta2) > AtomicHashMap locking issue [optimistic] > ---------------------------------------- > > Key: ISPN-2995 > URL: https://issues.jboss.org/browse/ISPN-2995 > Project: Infinispan > Issue Type: Bug > Components: Fine-grained API > Affects Versions: 5.3.0.Alpha1 > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Labels: atomic_map, locking > Fix For: 5.3.0.CR1 > > > In OptimisticLockingInterceptor, we are collecting the composite keys from ApplyDeltaCommand is the key belongs to the node: > {code} > case ApplyDeltaCommand.COMMAND_ID: > ApplyDeltaCommand command = (ApplyDeltaCommand) wc; > if (cdl.localNodeIsOwner(command.getKey())) { > Object[] compositeKeys = command.getCompositeKeys(); > set.addAll(Arrays.asList(compositeKeys)); > } > break; > {code} > However, when we are going to acquire the lock in the node if it is the primary owner: > {code} > protected final void lockAndRegisterBackupLock(TxInvocationContext ctx, Object key, long lockTimeout, boolean skipLocking) throws InterruptedException { > if (cdl.localNodeIsPrimaryOwner(key)) { > lockKeyAndCheckOwnership(ctx, key, lockTimeout, skipLocking); > } else if (cdl.localNodeIsOwner(key)) { > ctx.getCacheTransaction().addBackupLockForKey(key); > } > } > {code} > The CompositeKey should always acquire the lock. > This is probably a bug. Add an unit test to verify that locking works as expected for AtomicHashMap. -- 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

12 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2976) Log4J dependencies in codebase to be cleaned up

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2976?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2976: -------------------------------- Fix Version/s: 5.3.0.CR1 (was: 5.3.0.Beta2) > Log4J dependencies in codebase to be cleaned up > ----------------------------------------------- > > Key: ISPN-2976 > URL: https://issues.jboss.org/browse/ISPN-2976 > Project: Infinispan > Issue Type: Task > Affects Versions: 5.2.5.Final > Reporter: Manik Surtani > Assignee: Mircea Markus > Fix For: 5.3.0.CR1, 5.3.0.Final > > > When attempting to move to Log4J 2.0, I've noticed a number of hard deps on log4j classes. > {{SampleConfigFilesCorrectnessTest}} - this class makes use of a custom appender to analyse what a user is being warned of when a config file is parsed. Why are we using Log4J for this? Our own logging interface should be mocked and messages captured directly. > {{RehashStressTest}} and {{NucleotideCache}} - seems like a bug, I presume the author intended to use {{org.infinispan.logging.Log}}. > {{CompressedFileAppender}} and {{ThreadNameFilter}}- can this be written in a way that works with Log4J 1.x as well as 2.x? Or have the SPIs changed that much? -- 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

12 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3076) Infinispan should enable use of log4j2

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3076?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3076: -------------------------------- Fix Version/s: 5.3.0.CR1 (was: 5.3.0.Beta2) > Infinispan should enable use of log4j2 > -------------------------------------- > > Key: ISPN-3076 > URL: https://issues.jboss.org/browse/ISPN-3076 > Project: Infinispan > Issue Type: Enhancement > Components: Querying > Affects Versions: 5.2.5.Final > Environment: Any > Reporter: Divya Mehra > Assignee: Mircea Markus > Fix For: 5.3.0.CR1, 5.3.0.Final > > > log4j locks up on a certain amount of load, especially under concurrent access. The recommendation was to move up to log4j2. This can be done by removing > 1 JAR (log4j.jar) and adding 2 JARs (log4j-bridge and log4j-core.jar). > Also refer: https://issues.jboss.org/browse/ISPN-2976 -- 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

12 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3073) Remove deprecated configuration elements from default JGroups config

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3073?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3073: -------------------------------- Fix Version/s: 5.3.0.CR1 (was: 5.3.0.Beta2) > Remove deprecated configuration elements from default JGroups config > -------------------------------------------------------------------- > > Key: ISPN-3073 > URL: https://issues.jboss.org/browse/ISPN-3073 > Project: Infinispan > Issue Type: Task > Components: Server > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Priority: Minor > Fix For: 5.3.0.CR1 > > -- 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

12 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3062) Add streamLogs=true to JCache testsuite to see TCK output log in console

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3062?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3062: -------------------------------- Fix Version/s: 5.3.0.CR1 (was: 5.3.0.Beta2) > Add streamLogs=true to JCache testsuite to see TCK output log in console > ------------------------------------------------------------------------ > > Key: ISPN-3062 > URL: https://issues.jboss.org/browse/ISPN-3062 > Project: Infinispan > Issue Type: Task > Components: JCache > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 5.3.0.CR1 > > -- 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

12 years, 11 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues May 2013