[JBoss JIRA] (ISPN-4012) Timeout errors in the mass indexing tests
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-4012?page=com.atlassian.jira.plugin.... ]
Adrian Nistor commented on ISPN-4012:
-------------------------------------
This issue also appears for MassIndexingTest
> Timeout errors in the mass indexing tests
> -----------------------------------------
>
> Key: ISPN-4012
> URL: https://issues.jboss.org/browse/ISPN-4012
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Test Suite - Query
> Affects Versions: 6.0.1.Final
> Reporter: Dan Berindei
> Assignee: Sanne Grinovero
> Labels: 630
> Fix For: 7.0.0.Beta1
>
>
> Both DistProgrammaticMassIndexTest and TopologyAwareDistMassIndexingTest failed in CI today: http://ci.infinispan.org/viewLog.html?buildId=6578&tab=buildResultsDiv&bu...
> {noformat}
> org.infinispan.util.concurrent.TimeoutException: Node DistProgrammaticMassIndexTest-NodeC-7069 timed out
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:174)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:521)
> at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:280)
> at org.infinispan.query.indexmanager.InfinispanCommandsBackend.sendCommand(InfinispanCommandsBackend.java:87)
> at org.infinispan.query.indexmanager.InfinispanCommandsBackend.applyWork(InfinispanCommandsBackend.java:81)
> at org.infinispan.query.indexmanager.MasterSwitchDelegatingQueueProcessor.applyWork(MasterSwitchDelegatingQueueProcessor.java:53)
> at org.hibernate.search.indexes.impl.DirectoryBasedIndexManager.performOperations(DirectoryBasedIndexManager.java:126)
> at org.hibernate.search.backend.impl.WorkQueuePerIndexSplitter.commitOperations(WorkQueuePerIndexSplitter.java:63)
> at org.hibernate.search.backend.impl.BatchedQueueingProcessor.performWorks(BatchedQueueingProcessor.java:99)
> at org.hibernate.search.backend.impl.TransactionalWorker.performWork(TransactionalWorker.java:105)
> at org.infinispan.query.backend.QueryInterceptor.performSearchWorks(QueryInterceptor.java:232)
> at org.infinispan.query.backend.QueryInterceptor.purgeAllIndexes(QueryInterceptor.java:207)
> at org.infinispan.query.backend.QueryInterceptor.purgeAllIndexes(QueryInterceptor.java:199)
> at org.infinispan.query.impl.massindex.MapReduceMassIndexer.wipeExistingIndexes(MapReduceMassIndexer.java:33)
> at org.infinispan.query.impl.massindex.MapReduceMassIndexer.start(MapReduceMassIndexer.java:24)
> at org.infinispan.query.distributed.DistributedMassIndexingTest.rebuildIndexes(DistributedMassIndexingTest.java:75)
> at org.infinispan.query.distributed.DistributedMassIndexingTest.testReindexing(DistributedMassIndexingTest.java:63)
> Caused by: org.jgroups.TimeoutException: timeout sending message to DistProgrammaticMassIndexTest-NodeC-7069
> at org.jgroups.blocks.MessageDispatcher.sendMessage(MessageDispatcher.java:419)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.processSingleCall(CommandAwareRpcDispatcher.java:349)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:167)
> ... 37 more
> {noformat}
> Full logs: http://ci.infinispan.org/repository/download/bt2/6578:id/logs-638.zip
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (ISPN-4043) MassIndexingTest.testReindex random failures
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-4043?page=com.atlassian.jira.plugin.... ]
Adrian Nistor resolved ISPN-4043.
---------------------------------
Resolution: Duplicate Issue
> MassIndexingTest.testReindex random failures
> --------------------------------------------
>
> Key: ISPN-4043
> URL: https://issues.jboss.org/browse/ISPN-4043
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Test Suite - Query
> Affects Versions: 6.0.1.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Labels: testsuite_stability
> Fix For: 7.0.0.Beta1
>
>
> http://ci.infinispan.org/viewLog.html?buildId=6695&tab=buildResultsDiv&bu...
> {noformat}
> org.infinispan.commons.CacheException: org.infinispan.util.concurrent.TimeoutException: Node MassIndexingTest-NodeC-30523 timed out
> at org.infinispan.distexec.mapreduce.MapReduceTask.execute(MapReduceTask.java:350)
> at org.infinispan.query.impl.massindex.MapReduceMassIndexer.start(MapReduceMassIndexer.java:25)
> at org.infinispan.query.distributed.DistributedMassIndexingTest.rebuildIndexes(DistributedMassIndexingTest.java:75)
> at org.infinispan.query.distributed.MassIndexingTest.testReindexing(MassIndexingTest.java:34)
> Caused by: org.infinispan.util.concurrent.TimeoutException: Node MassIndexingTest-NodeC-30523 timed out
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:174)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:521)
> at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:280)
> at org.infinispan.query.indexmanager.InfinispanCommandsBackend.sendCommand(InfinispanCommandsBackend.java:87)
> at org.infinispan.query.indexmanager.InfinispanCommandsBackend.applyWork(InfinispanCommandsBackend.java:81)
> at org.infinispan.query.indexmanager.InfinispanCommandsBackend.applyStreamWork(InfinispanCommandsBackend.java:93)
> at org.infinispan.query.indexmanager.MasterSwitchDelegatingQueueProcessor.applyStreamWork(MasterSwitchDelegatingQueueProcessor.java:63)
> at org.hibernate.search.indexes.impl.DirectoryBasedIndexManager.performStreamOperation(DirectoryBasedIndexManager.java:121)
> at org.hibernate.search.backend.impl.StreamingSelectionVisitor$AddSelectionDelegate.performStreamOperation(StreamingSelectionVisitor.java:99)
> at org.hibernate.search.backend.impl.batch.DefaultBatchBackend.sendWorkToShards(DefaultBatchBackend.java:75)
> at org.hibernate.search.backend.impl.batch.DefaultBatchBackend.enqueueAsyncWork(DefaultBatchBackend.java:62)
> at org.infinispan.query.impl.massindex.IndexingReducer.reduce(IndexingReducer.java:39)
> at org.infinispan.query.impl.massindex.IndexingReducer.reduce(IndexingReducer.java:20)
> at org.infinispan.distexec.mapreduce.MapReduceTask.executeMapPhaseWithLocalReduction(MapReduceTask.java:496)
> at org.infinispan.distexec.mapreduce.MapReduceTask.execute(MapReduceTask.java:348)
> ... 24 more
> Caused by: org.jgroups.TimeoutException: timeout sending message to MassIndexingTest-NodeC-30523
> at org.jgroups.blocks.MessageDispatcher.sendMessage(MessageDispatcher.java:419)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.processSingleCall(CommandAwareRpcDispatcher.java:349)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:167)
> ... 38 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (ISPN-4409) LevelDBCacheStoreIT fails to initialise with com.arjuna.ats.arjuna.exceptions.FatalError
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-4409?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated ISPN-4409:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
Integrated in master. Thanks!
> LevelDBCacheStoreIT fails to initialise with com.arjuna.ats.arjuna.exceptions.FatalError
> ----------------------------------------------------------------------------------------
>
> Key: ISPN-4409
> URL: https://issues.jboss.org/browse/ISPN-4409
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Test Suite - Server
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 7.0.0.Alpha5
>
>
> The LevelDBCacheStoreIT fails to start with an error resulting from initialising the server side cache marshaller. The way the cache manager is created is not correct. You might as well just use the same marshaller as for the client.
> Even if you really need a cache's marshaller, you should get it via an injected cache rather than initialising a cache from scratch.
> {code}com.arjuna.ats.arjuna.exceptions.FatalError: null
> at com.arjuna.ats.internal.jts.ORBManager.getPOA(ORBManager.java:96)
> at com.arjuna.ats.internal.jts.OTSImpleManager.<clinit>(OTSImpleManager.java:300)
> at com.arjuna.ats.internal.jta.transaction.jts.TransactionImple.getTransaction(TransactionImple.java:1146)
> at com.arjuna.ats.internal.jta.transaction.jts.TransactionManagerImple.getTransaction(TransactionManagerImple.java:69)
> at org.infinispan.cache.impl.CacheImpl.getOngoingTransaction(CacheImpl.java:1414)
> at org.infinispan.cache.impl.CacheImpl.getInvocationContextForRead(CacheImpl.java:592)
> at org.infinispan.cache.impl.CacheImpl.keySet(CacheImpl.java:474)
> at org.infinispan.cache.impl.CacheImpl.keySet(CacheImpl.java:469)
> at org.infinispan.registry.impl.ClusterRegistryImpl.keys(ClusterRegistryImpl.java:81)
> at org.infinispan.query.remote.ProtobufMetadataManager.ensureInit(ProtobufMetadataManager.java:67)
> at org.infinispan.query.remote.ProtobufMetadataManager.getSerializationContext(ProtobufMetadataManager.java:132)
> at org.infinispan.query.remote.LifecycleManager.cacheStarting(LifecycleManager.java:114)
> at org.infinispan.factories.ComponentRegistry.notifyCacheStarting(ComponentRegistry.java:228)
> at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:214)
> at org.infinispan.cache.impl.CacheImpl.start(CacheImpl.java:699)
> at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:573)
> at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:528)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:408)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:381)
> at org.infinispan.server.test.cs.leveldb.LevelDBCacheStoreIT.getServerMarshaller(LevelDBCacheStoreIT.java:190)
> at org.infinispan.server.test.cs.leveldb.LevelDBCacheStoreIT.<clinit>(LevelDBCacheStoreIT.java:67)
> « Hide stacktrace{code}
> The fix gets past this particular error but it still shows this afterwards:
> {code}Caused by: javax.management.InstanceNotFoundException: jboss.infinispan:type=Server,name=HotRod,component=Transport{code}
> Tristan is working on this...
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (ISPN-4296) Restore predefined cache limitation for Hot Rod servers
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4296?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated ISPN-4296:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1110686
> Restore predefined cache limitation for Hot Rod servers
> -------------------------------------------------------
>
> Key: ISPN-4296
> URL: https://issues.jboss.org/browse/ISPN-4296
> Project: Infinispan
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Remote Protocols
> Affects Versions: 7.0.0.Alpha3
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 7.0.0.Alpha5, 7.0.0.Beta1
>
>
> Even after asymmetric cluster support was implemented, each node still does not know which other nodes contain which caches. The coordinator of the cluster knows, but no one else. This is because the aim has never really been to have different nodes containing different caches, but more about making sure that caches can be started lazily. With this in mind, the limitation in ISPN-833 will be reinstated.
> Being able to work only with predefined caches also simplifies a solution for ISPN-3530 because we can safely assume that all servers contain the defined caches. Each cache might have a different consistent hash (see dev list discussion on why this can easily happen - http://lists.jboss.org/pipermail/infinispan-dev/2014-April/014870.html) but at least knowing that the nodes that have it is the same makes it easier to come up with a solution.
> Finally, restoring the limitation avoids other can of worms such as the edge cases discovered by Jakub in ISPN-4212.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (ISPN-4386) JmxManagementIT.testCacheManagerAttributes test failure
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4386?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4386:
-----------------------------------------------
Tomas Sykora <tsykora(a)redhat.com> changed the Status of [bug 1108122|https://bugzilla.redhat.com/show_bug.cgi?id=1108122] from ON_QA to VERIFIED
> JmxManagementIT.testCacheManagerAttributes test failure
> -------------------------------------------------------
>
> Key: ISPN-4386
> URL: https://issues.jboss.org/browse/ISPN-4386
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: William Burns
> Assignee: William Burns
> Fix For: 7.0.0.Alpha5
>
>
> This test fails every time with
> {code}
> java.lang.AssertionError: expected:<3> but was:<4>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:743)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:555)
> at org.junit.Assert.assertEquals(Assert.java:542)
> at org.infinispan.server.test.jmx.management.JmxManagementIT.testCacheManagerAttributes(JmxManagementIT.java:174)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at org.jboss.arquillian.junit.Arquillian$6$1.invoke(Arquillian.java:270)
> at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
> at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> at org.jboss.arquillian.container.test.impl.execution.ClientTestExecuter.execute(ClientTestExecuter.java:53)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142)
> at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createTestContext(ContainerEventController.java:129)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:89)
> at sun.reflect.GeneratedMethodAccessor16.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75)
> at sun.reflect.GeneratedMethodAccessor15.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60)
> at sun.reflect.GeneratedMethodAccessor14.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
> at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:111)
> at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:263)
> at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:226)
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
> at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
> at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:240)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:185)
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
> at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
> at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:199)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147)
> at org.junit.runners.Suite.runChild(Suite.java:127)
> at org.junit.runners.Suite.runChild(Suite.java:26)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:138)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:62)
> at org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:139)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> 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:115)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
> {code}
> looking into it deeper it looks like this is caused by a new cache being installed in the server of __cluster_registry_cache__.
> http://ci.infinispan.org/viewLog.html?buildId=8736&buildTypeId=bt8&tab=bu...
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (ISPN-4415) CacheContainerIT failing with ClassCastException
by Galder Zamarreño (JIRA)
Galder Zamarreño created ISPN-4415:
--------------------------------------
Summary: CacheContainerIT failing with ClassCastException
Key: ISPN-4415
URL: https://issues.jboss.org/browse/ISPN-4415
Project: Infinispan
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Configuration, Test Suite - Server
Affects Versions: 7.0.0.Alpha2
Reporter: Galder Zamarreño
Assignee: Galder Zamarreño
Fix For: 7.0.0.Alpha5
org.infinispan.server.test.cache.container.CacheContainerIT is failing with:
{code}10:27:52,567 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service jboss.infinispan.default.default: org.jboss.msc.service.StartException in service jboss.infinispan.default.default: Failed to start service
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_60]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_60]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_60]
Caused by: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.eviction.impl.EvictionManagerImpl.start() on object of type EvictionManagerImpl
at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:170)
at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869)
at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638)
at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627)
at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530)
at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:216)
at org.infinispan.cache.impl.CacheImpl.start(CacheImpl.java:699)
at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:573)
at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:528)
at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:408)
at org.infinispan.registry.impl.ClusterRegistryImpl.startRegistryCache(ClusterRegistryImpl.java:146)
at org.infinispan.registry.impl.ClusterRegistryImpl.addListener(ClusterRegistryImpl.java:107)
at org.infinispan.query.remote.ProtobufMetadataManager.ensureInit(ProtobufMetadataManager.java:65)
at org.infinispan.query.remote.ProtobufMetadataManager.getSerializationContext(ProtobufMetadataManager.java:132)
at org.infinispan.query.remote.LifecycleManager.cacheStarting(LifecycleManager.java:114)
at org.infinispan.factories.ComponentRegistry.notifyCacheStarting(ComponentRegistry.java:228)
at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:214)
at org.infinispan.cache.impl.CacheImpl.start(CacheImpl.java:699)
at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:573)
at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:528)
at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:408)
at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:422)
at org.jboss.as.clustering.infinispan.DefaultEmbeddedCacheManager.getCache(DefaultEmbeddedCacheManager.java:89)
at org.jboss.as.clustering.infinispan.DefaultEmbeddedCacheManager.getCache(DefaultEmbeddedCacheManager.java:80)
at org.jboss.as.clustering.infinispan.subsystem.SecurityActions$5.run(SecurityActions.java:101)
at org.jboss.as.clustering.infinispan.subsystem.SecurityActions$5.run(SecurityActions.java:98)
at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_60]
at org.jboss.as.clustering.infinispan.subsystem.SecurityActions.startCache(SecurityActions.java:109)
at org.jboss.as.clustering.infinispan.subsystem.CacheService.start(CacheService.java:78)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
... 3 more
Caused by: java.lang.ClassCastException: org.jboss.as.clustering.concurrent.ManagedExecutorService cannot be cast to java.util.concurrent.ScheduledExecutorService
at org.infinispan.executors.LazyInitializingScheduledExecutorService.initIfNeeded(LazyInitializingScheduledExecutorService.java:40)
at org.infinispan.executors.LazyInitializingScheduledExecutorService.scheduleWithFixedDelay(LazyInitializingScheduledExecutorService.java:146)
at org.infinispan.eviction.impl.EvictionManagerImpl.start(EvictionManagerImpl.java:77)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_60]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_60]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_60]
at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_60]
at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168)
... 33 more{code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (ISPN-2956) putIfAbsent on Hot Rod Java client doesn't reliably fulfil contract
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-2956?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-2956:
-----------------------------------
Status: Pull Request Sent (was: Coding In Progress)
Git Pull Request: https://github.com/infinispan/infinispan/pull/2653
> putIfAbsent on Hot Rod Java client doesn't reliably fulfil contract
> -------------------------------------------------------------------
>
> Key: ISPN-2956
> URL: https://issues.jboss.org/browse/ISPN-2956
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Remote Protocols
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Labels: 63gablocker, hotrod-java-client, remote-clients
> Fix For: 7.0.0.Beta1
>
>
> Hot Rod's putIfAbsent might have issues on some edge cases:
> {quote}I want to know whether the putting entry already exists in the remote
> cache cluster, or not.
> I thought that RemoteCache.putIfAbsent() would be useful for that
> purpose, i.e.,
> {code}
> if (remoteCache.putIfAbsent(k,v) == null) {
> // new entry.
> } else {
> // k already exists.
> }
> {code}
> But no.
> The putIfAbsent() for new entry may return non-null value, if one of the
> server crushed while putting.
> The behavior is like the following:
> 1. Client do putIfAbsent(k,v).
> 2. The server receives the request and sends replication requests to
> other servers. If the server crushed before completing replication, some
> servers own that (k,v), but others not.
> 3. Client receives the error. The putIfAbsent() internally retries the
> same request to the next server in the cluster server list.
> 4. If the next server owns the (k,v), the putIfAbsent() returns the
> replicated (k,v) at the step 2, without any error.
> So, putIfAbsent() is not reliable for knowing whether the putting entry
> is *exactly* new or not.
> Does anyone have any idea/workaround for this purpose?{quote}
> A workaround is to do this:
> {quote}We got a simple solution, which can be applied to our customer's application.
> If each value part of putting (k,v) is unique or contains unique value,
> the client can do *double check* wether the entry is new.
> {code}
> val = System.nanoTime(); // or uuid is also useful.
> if ((ret = cache.putIfAbsent(key, val)) == null
> || ret.equals(val)) {
> // new entry, if the return value is just the same.
> } else {
> // key already exists.
> }
> {code}
> We are proposing this workaround which almost works fine.{quote}
> However, this is a bit of a cludge.
> Hot Rod should be improved with an operation that allows a version to be passed when entry is created, instead of relying on the client generating it.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (ISPN-2956) putIfAbsent on Hot Rod Java client doesn't reliably fulfil contract
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-2956?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño commented on ISPN-2956:
----------------------------------------
After trying the solution mentioned above, it became clear that it'd only work for those situations where the previous value was non-existent, e.g. for putIfAbsent() operations, so this option has been abandoned. As indicated in the mail thread (see http://lists.jboss.org/pipermail/infinispan-dev/2014-June/015079.html), the return of all conditional operations, including putIfAbsent(), and those that return previous value, can only be guaranteed when the cache is transactional and the rollback phase can guarantee that state is not partially applied. The pull request about to be sent adds some tests that verify this, and adds warn messages when either conditional operations or previous values need to be returned, and the cache is not transactional.
> putIfAbsent on Hot Rod Java client doesn't reliably fulfil contract
> -------------------------------------------------------------------
>
> Key: ISPN-2956
> URL: https://issues.jboss.org/browse/ISPN-2956
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Remote Protocols
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Labels: 63gablocker, hotrod-java-client, remote-clients
> Fix For: 7.0.0.Beta1
>
>
> Hot Rod's putIfAbsent might have issues on some edge cases:
> {quote}I want to know whether the putting entry already exists in the remote
> cache cluster, or not.
> I thought that RemoteCache.putIfAbsent() would be useful for that
> purpose, i.e.,
> {code}
> if (remoteCache.putIfAbsent(k,v) == null) {
> // new entry.
> } else {
> // k already exists.
> }
> {code}
> But no.
> The putIfAbsent() for new entry may return non-null value, if one of the
> server crushed while putting.
> The behavior is like the following:
> 1. Client do putIfAbsent(k,v).
> 2. The server receives the request and sends replication requests to
> other servers. If the server crushed before completing replication, some
> servers own that (k,v), but others not.
> 3. Client receives the error. The putIfAbsent() internally retries the
> same request to the next server in the cluster server list.
> 4. If the next server owns the (k,v), the putIfAbsent() returns the
> replicated (k,v) at the step 2, without any error.
> So, putIfAbsent() is not reliable for knowing whether the putting entry
> is *exactly* new or not.
> Does anyone have any idea/workaround for this purpose?{quote}
> A workaround is to do this:
> {quote}We got a simple solution, which can be applied to our customer's application.
> If each value part of putting (k,v) is unique or contains unique value,
> the client can do *double check* wether the entry is new.
> {code}
> val = System.nanoTime(); // or uuid is also useful.
> if ((ret = cache.putIfAbsent(key, val)) == null
> || ret.equals(val)) {
> // new entry, if the return value is just the same.
> } else {
> // key already exists.
> }
> {code}
> We are proposing this workaround which almost works fine.{quote}
> However, this is a bit of a cludge.
> Hot Rod should be improved with an operation that allows a version to be passed when entry is created, instead of relying on the client generating it.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (ISPN-2956) putIfAbsent on Hot Rod Java client doesn't reliably fulfil contract
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-2956?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-2956:
-----------------------------------
Forum Reference: http://lists.jboss.org/pipermail/infinispan-dev/2014-June/015079.html
> putIfAbsent on Hot Rod Java client doesn't reliably fulfil contract
> -------------------------------------------------------------------
>
> Key: ISPN-2956
> URL: https://issues.jboss.org/browse/ISPN-2956
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Remote Protocols
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Labels: 63gablocker, hotrod-java-client, remote-clients
> Fix For: 7.0.0.Beta1
>
>
> Hot Rod's putIfAbsent might have issues on some edge cases:
> {quote}I want to know whether the putting entry already exists in the remote
> cache cluster, or not.
> I thought that RemoteCache.putIfAbsent() would be useful for that
> purpose, i.e.,
> {code}
> if (remoteCache.putIfAbsent(k,v) == null) {
> // new entry.
> } else {
> // k already exists.
> }
> {code}
> But no.
> The putIfAbsent() for new entry may return non-null value, if one of the
> server crushed while putting.
> The behavior is like the following:
> 1. Client do putIfAbsent(k,v).
> 2. The server receives the request and sends replication requests to
> other servers. If the server crushed before completing replication, some
> servers own that (k,v), but others not.
> 3. Client receives the error. The putIfAbsent() internally retries the
> same request to the next server in the cluster server list.
> 4. If the next server owns the (k,v), the putIfAbsent() returns the
> replicated (k,v) at the step 2, without any error.
> So, putIfAbsent() is not reliable for knowing whether the putting entry
> is *exactly* new or not.
> Does anyone have any idea/workaround for this purpose?{quote}
> A workaround is to do this:
> {quote}We got a simple solution, which can be applied to our customer's application.
> If each value part of putting (k,v) is unique or contains unique value,
> the client can do *double check* wether the entry is new.
> {code}
> val = System.nanoTime(); // or uuid is also useful.
> if ((ret = cache.putIfAbsent(key, val)) == null
> || ret.equals(val)) {
> // new entry, if the return value is just the same.
> } else {
> // key already exists.
> }
> {code}
> We are proposing this workaround which almost works fine.{quote}
> However, this is a bit of a cludge.
> Hot Rod should be improved with an operation that allows a version to be passed when entry is created, instead of relying on the client generating it.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (ISPN-4291) Poor REPL state transfer performance with cache stores
by Dennis Reed (JIRA)
[ https://issues.jboss.org/browse/ISPN-4291?page=com.atlassian.jira.plugin.... ]
Dennis Reed commented on ISPN-4291:
-----------------------------------
In addition, this step currently blocks writes to the cache until it completes.
As you stated on the support list discussion: "I think it should be ok to remove data from the cache store afterwards, without blocking writes."
> Poor REPL state transfer performance with cache stores
> ------------------------------------------------------
>
> Key: ISPN-4291
> URL: https://issues.jboss.org/browse/ISPN-4291
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: State Transfer
> Affects Versions: 6.0.2.Final
> Reporter: Dennis Reed
> Assignee: Dan Berindei
>
> During a state transfer every single key is loaded from the cache store to determine whether it's still owned by the local node.
> This is an extremely slow operation, and doesn't even make sense for a REPL cache.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months