[JBoss JIRA] (ISPN-4051) ProtoStream fails to resolve dependencies correctly
by Tristan Tarrant (JIRA)
Tristan Tarrant created ISPN-4051:
-------------------------------------
Summary: ProtoStream fails to resolve dependencies correctly
Key: ISPN-4051
URL: https://issues.jboss.org/browse/ISPN-4051
Project: Infinispan
Issue Type: Bug
Reporter: Tristan Tarrant
Assignee: Adrian Nistor
Attempting to import a ProtoBuf definition which uses imports fails with:
Caused by: com.google.protobuf.Descriptors$DescriptorValidationException: AeiReaderMessage_M.proto: Dependencies passed to FileDescriptor.buildFrom() don't match those listed in the FileDescriptorProto.
at com.google.protobuf.Descriptors$FileDescriptor.buildFrom(Descriptors.java:240)
at org.infinispan.protostream.impl.SerializationContextImpl.registerProtofile(SerializationContextImpl.java:61)
at org.infinispan.query.remote.ProtobufMetadataManager$ProtobufMetadataRegistryListener.registerProtofile(ProtobufMetadataManager.java:154)
at org.infinispan.query.remote.ProtobufMetadataManager$ProtobufMetadataRegistryListener.modified(ProtobufMetadataManager.java:149)
This is caused by the fact that SerializationContextImpl#resolveDeps returns an empty array even though the inlcuded file is actually in the definition.
--
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, 1 month
[JBoss JIRA] (ISPN-4018) Write skew should not be check if conditional operations does not change the value
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-4018?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo commented on ISPN-4018:
-----------------------------------
I don't agree with you. If you are going to check all the keys, then you are entering in one-copy serializability (1CS) isolation level.
A transaction system is a set of reads and/or writes in a shared state, and we can look in conditional commands as:
{code}
if (isConditionMet(read(x), expected-value)) { write(x, new-value) }
{code}
For ISPN (and for me), tx1 should not fail in this scenario (assuming initially x = y):
{code}
tx1: read(x) //return y
tx2: write(x, w)
tx1: putIfAbsent(x, z) //no-op since x's value is y
{code}
and it should fail in this:
{code}
tx1: read(x) //read y
tx2: write(x,w)
tx1: putIfAbsent(x,z) //no-op since x's value is y
//read(x) will return read y in tx1
tx1: write(x,u)
{code}
> Write skew should not be check if conditional operations does not change the value
> ----------------------------------------------------------------------------------
>
> Key: ISPN-4018
> URL: https://issues.jboss.org/browse/ISPN-4018
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Transactions
> Affects Versions: 6.0.1.Final
> Reporter: Pedro Ruivo
> Assignee: Pedro Ruivo
> Fix For: 7.0.0.Alpha1, 7.0.0.Final
>
>
> Currently, if a conditional operation does no perform the update, we still perform the check. however, the write never happened. It simple makes no sense.
> However, if a write succeeds after, the write skew check must be performed for the key.
--
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, 1 month
[JBoss JIRA] (ISPN-4013) Improve MapReduceTask timeout exception messages
by Vladimir Blagojevic (JIRA)
[ https://issues.jboss.org/browse/ISPN-4013?page=com.atlassian.jira.plugin.... ]
Vladimir Blagojevic commented on ISPN-4013:
-------------------------------------------
New stacktrace looks like this:
testInvokeMapReduceOnAllKeys(org.infinispan.distexec.mapreduce.LargeDistributedFourNodesMapReduceTest) Time elapsed: 10.876 sec <<< FAILURE!
org.infinispan.commons.CacheException: java.util.concurrent.ExecutionException: Map phase executing at LargeDistributedFourNodesMapReduceTest-NodeA-20949 did not complete within 2 sec timeout
at org.infinispan.distexec.mapreduce.MapReduceTask.execute(MapReduceTask.java:338)
at org.infinispan.distexec.mapreduce.BaseLargeWordCountMapReduceTest.testInvokeMapReduceOnAllKeys(BaseLargeWordCountMapReduceTest.java:59)
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.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
at org.testng.TestRunner.privateRun(TestRunner.java:767)
at org.testng.TestRunner.run(TestRunner.java:617)
at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
at org.testng.SuiteRunner.access$000(SuiteRunner.java:37)
at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:368)
at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
Caused by: java.util.concurrent.ExecutionException: Map phase executing at LargeDistributedFourNodesMapReduceTest-NodeA-20949 did not complete within 2 sec timeout
at org.infinispan.distexec.mapreduce.MapReduceTask.executeMapPhase(MapReduceTask.java:443)
at org.infinispan.distexec.mapreduce.MapReduceTask.execute(MapReduceTask.java:332)
... 21 more
Caused by: org.infinispan.util.concurrent.TimeoutException: Node LargeDistributedFourNodesMapReduceTest-NodeB-57944 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.remoting.rpc.RpcManagerImpl$2.call(RpcManagerImpl.java:312)
... 4 more
Caused by: org.jgroups.TimeoutException: timeout sending message to LargeDistributedFourNodesMapReduceTest-NodeB-57944
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)
... 7 more
> Improve MapReduceTask timeout exception messages
> ------------------------------------------------
>
> Key: ISPN-4013
> URL: https://issues.jboss.org/browse/ISPN-4013
> Project: Infinispan
> Issue Type: Enhancement
> Reporter: Vladimir Blagojevic
> Assignee: Vladimir Blagojevic
>
> Currently we just let TimoutException from RPC call propagate up the stack which confuses users as they do not understand why timeout even occurred.
--
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, 1 month
[JBoss JIRA] (ISPN-4049) Race condition during startup if a JDBCstore use the datasource
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4049?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated ISPN-4049:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1067916
> Race condition during startup if a JDBCstore use the datasource
> ---------------------------------------------------------------
>
> Key: ISPN-4049
> URL: https://issues.jboss.org/browse/ISPN-4049
> Project: Infinispan
> Issue Type: Bug
> Reporter: Wolf-Dieter Fink
> Assignee: Mircea Markus
>
> It looks like that the infinispan subsystem does not have a dependency to the datasource subsystem and both are started in parallel.
> Sporadically it happens that the JDBCstore is accessing the datasource for preloading the cache but the datasource is not ready.
> The test is a single StringKeyedJdbcStore cache (replicated, preloaded, no eviction)
> From the log it is shown that the DS is bound a couple of millis after the failure:
> xx:xx:xx,849 ERROR
> Caused by: org.infinispan.CacheException: Unable to start cache loaders
> Caused by: org.infinispan.loaders.CacheLoaderException: javax.naming.NameNotFoundException: Error looking up datasources/OracleDS, service service jboss.naming.context.java.jboss.datasources.OracleDS is not started
> Caused by: javax.naming.NameNotFoundException: Error looking up datasources/OracleDS, service service jboss.naming.context.java.jboss.datasources.OracleDS is not started
> xx:xx:xx,860 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-5) JBAS010400: Bound data source [java:jboss/datasources/OracleDS]
--
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, 1 month
[JBoss JIRA] (ISPN-4049) Race condition during startup if a JDBCstore use the datasource
by Wolf-Dieter Fink (JIRA)
[ https://issues.jboss.org/browse/ISPN-4049?page=com.atlassian.jira.plugin.... ]
Wolf-Dieter Fink updated ISPN-4049:
-----------------------------------
Affects Version/s: 6.0.1.Final
> Race condition during startup if a JDBCstore use the datasource
> ---------------------------------------------------------------
>
> Key: ISPN-4049
> URL: https://issues.jboss.org/browse/ISPN-4049
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 6.0.1.Final
> Reporter: Wolf-Dieter Fink
> Assignee: Mircea Markus
>
> It looks like that the infinispan subsystem does not have a dependency to the datasource subsystem and both are started in parallel.
> Sporadically it happens that the JDBCstore is accessing the datasource for preloading the cache but the datasource is not ready.
> The test is a single StringKeyedJdbcStore cache (replicated, preloaded, no eviction)
> From the log it is shown that the DS is bound a couple of millis after the failure:
> xx:xx:xx,849 ERROR
> Caused by: org.infinispan.CacheException: Unable to start cache loaders
> Caused by: org.infinispan.loaders.CacheLoaderException: javax.naming.NameNotFoundException: Error looking up datasources/OracleDS, service service jboss.naming.context.java.jboss.datasources.OracleDS is not started
> Caused by: javax.naming.NameNotFoundException: Error looking up datasources/OracleDS, service service jboss.naming.context.java.jboss.datasources.OracleDS is not started
> xx:xx:xx,860 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-5) JBAS010400: Bound data source [java:jboss/datasources/OracleDS]
--
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, 1 month
[JBoss JIRA] (ISPN-4049) Race condition during startup if a JDBCstore use the datasource
by Wolf-Dieter Fink (JIRA)
Wolf-Dieter Fink created ISPN-4049:
--------------------------------------
Summary: Race condition during startup if a JDBCstore use the datasource
Key: ISPN-4049
URL: https://issues.jboss.org/browse/ISPN-4049
Project: Infinispan
Issue Type: Bug
Reporter: Wolf-Dieter Fink
Assignee: Mircea Markus
It looks like that the infinispan subsystem does not have a dependency to the datasource subsystem and both are started in parallel.
Sporadically it happens that the JDBCstore is accessing the datasource for preloading the cache but the datasource is not ready.
The test is a single StringKeyedJdbcStore cache (replicated, preloaded, no eviction)
>From the log it is shown that the DS is bound a couple of millis after the failure:
xx:xx:xx,849 ERROR
Caused by: org.infinispan.CacheException: Unable to start cache loaders
Caused by: org.infinispan.loaders.CacheLoaderException: javax.naming.NameNotFoundException: Error looking up datasources/OracleDS, service service jboss.naming.context.java.jboss.datasources.OracleDS is not started
Caused by: javax.naming.NameNotFoundException: Error looking up datasources/OracleDS, service service jboss.naming.context.java.jboss.datasources.OracleDS is not started
xx:xx:xx,860 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-5) JBAS010400: Bound data source [java:jboss/datasources/OracleDS]
--
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, 1 month
[JBoss JIRA] (ISPN-4018) Write skew should not be check if conditional operations does not change the value
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-4018?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-4018:
------------------------------------
To me it makes sense to do the write skew check for all the values that were read by the transaction, regardless if they are written to or not. Of course, if the conditional operation was the only write in the transaction, then the transaction is effectively read-only and shouldn't be replicated at all.
> Write skew should not be check if conditional operations does not change the value
> ----------------------------------------------------------------------------------
>
> Key: ISPN-4018
> URL: https://issues.jboss.org/browse/ISPN-4018
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Transactions
> Affects Versions: 6.0.1.Final
> Reporter: Pedro Ruivo
> Assignee: Pedro Ruivo
> Fix For: 7.0.0.Alpha1, 7.0.0.Final
>
>
> Currently, if a conditional operation does no perform the update, we still perform the check. however, the write never happened. It simple makes no sense.
> However, if a write succeeds after, the write skew check must be performed for the key.
--
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, 1 month
[JBoss JIRA] (ISPN-4048) SharedCacheLoaderQueryIndexTest and SharedCacheLoaderQueryDistributedIndexTest always fail
by Dan Berindei (JIRA)
Dan Berindei created ISPN-4048:
----------------------------------
Summary: SharedCacheLoaderQueryIndexTest and SharedCacheLoaderQueryDistributedIndexTest always fail
Key: ISPN-4048
URL: https://issues.jboss.org/browse/ISPN-4048
Project: Infinispan
Issue Type: Bug
Components: Test Suite - Core
Affects Versions: 6.0.1.Final
Reporter: Dan Berindei
Assignee: Dan Berindei
Fix For: 7.0.0.Alpha1
The failures in CI have a different stack trace, they used an obsolete DummyInMemoryStore statistic name ("store" instead of "write").
{noformat}
16:32:40,025 ERROR (testng-SharedCacheLoaderQueryIndexTest:) [UnitTestTestNGListener] Test testPreloadIndexingAfterAddingNewNode(org.infinispan.query.persistence.SharedCacheLoaderQueryIndexTest) failed.
java.lang.AssertionError: expected:<1> but was:<0>
at org.testng.AssertJUnit.fail(AssertJUnit.java:59)
at org.testng.AssertJUnit.failNotEquals(AssertJUnit.java:364)
at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:80)
at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:245)
at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:252)
at org.infinispan.query.statetransfer.BaseReIndexingTest.executeSimpleQuery(BaseReIndexingTest.java:56)
at org.infinispan.query.statetransfer.BaseReIndexingTest$1.call(BaseReIndexingTest.java:109)
at org.infinispan.test.TestingUtil.withCacheManager(TestingUtil.java:1243)
at org.infinispan.query.statetransfer.BaseReIndexingTest.addNodeCheckingContentsAndQuery(BaseReIndexingTest.java:93)
at org.infinispan.query.persistence.SharedCacheLoaderQueryIndexTest.testPreloadIndexingAfterAddingNewNode(SharedCacheLoaderQueryIndexTest.java:49)
{noformat}
{noformat}
16:32:43,367 ERROR (testng-SharedCacheLoaderQueryDistributedIndexTest:) [UnitTestTestNGListener] Test testPreloadIndexingAfterAddingNewNode(org.infinispan.query.persistence.SharedCacheLoaderQueryDistributedIndexTest) failed.
java.lang.RuntimeException: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.persistence.manager.PersistenceManagerImpl.preload() on object of type PersistenceManagerImpl
at org.infinispan.query.statetransfer.BaseReIndexingTest$1.call(BaseReIndexingTest.java:111)
at org.infinispan.test.TestingUtil.withCacheManager(TestingUtil.java:1243)
at org.infinispan.query.statetransfer.BaseReIndexingTest.addNodeCheckingContentsAndQuery(BaseReIndexingTest.java:93)
at org.infinispan.query.persistence.SharedCacheLoaderQueryIndexTest.testPreloadIndexingAfterAddingNewNode(SharedCacheLoaderQueryIndexTest.java:49)
Caused by: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.persistence.manager.PersistenceManagerImpl.preload() on object of type PersistenceManagerImpl
at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:185)
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.CacheImpl.start(CacheImpl.java:674)
at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:553)
at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:516)
at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:398)
at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:371)
at org.infinispan.statetransfer.JoiningNode.getCache(JoiningNode.java:31)
at org.infinispan.query.statetransfer.BaseReIndexingTest$1.call(BaseReIndexingTest.java:99)
... 23 more
Caused by: org.infinispan.persistence.spi.PersistenceException: Unable to preload!
at org.infinispan.persistence.manager.PersistenceManagerImpl.preloadKey(PersistenceManagerImpl.java:614)
at org.infinispan.persistence.manager.PersistenceManagerImpl.access$000(PersistenceManagerImpl.java:66)
at org.infinispan.persistence.manager.PersistenceManagerImpl$1.processEntry(PersistenceManagerImpl.java:224)
at org.infinispan.persistence.dummy.DummyInMemoryStore.process(DummyInMemoryStore.java:159)
at org.infinispan.persistence.manager.PersistenceManagerImpl.preload(PersistenceManagerImpl.java:216)
at sun.reflect.GeneratedMethodAccessor69.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:183)
... 35 more
Caused by: java.lang.NullPointerException
at org.infinispan.distribution.DistributionManagerImpl.getWriteConsistentHash(DistributionManagerImpl.java:112)
at org.infinispan.distribution.DistributionManagerImpl.getConsistentHash(DistributionManagerImpl.java:102)
at org.infinispan.distribution.DistributionManagerImpl.getPrimaryLocation(DistributionManagerImpl.java:92)
at org.infinispan.query.indexmanager.InfinispanCommandsBackend.getPrimaryNodeAddress(InfinispanCommandsBackend.java:134)
at org.infinispan.query.indexmanager.InfinispanCommandsBackend.isMasterLocal(InfinispanCommandsBackend.java:112)
at org.infinispan.query.indexmanager.MasterSwitchDelegatingQueueProcessor.applyWork(MasterSwitchDelegatingQueueProcessor.java:47)
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.performSearchWork(QueryInterceptor.java:226)
at org.infinispan.query.backend.QueryInterceptor.updateIndexes(QueryInterceptor.java:220)
at org.infinispan.query.backend.QueryInterceptor.processPutKeyValueCommand(QueryInterceptor.java:522)
at org.infinispan.query.backend.QueryInterceptor.visitPutKeyValueCommand(QueryInterceptor.java:161)
at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:71)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitPutKeyValueCommand(AbstractLockingInterceptor.java:68)
at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:71)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112)
at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:32)
at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:71)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112)
at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:32)
at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:71)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
at org.infinispan.statetransfer.StateTransferInterceptor.handleNonTxWriteCommand(StateTransferInterceptor.java:205)
at org.infinispan.statetransfer.StateTransferInterceptor.visitPutKeyValueCommand(StateTransferInterceptor.java:141)
at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:71)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
at org.infinispan.interceptors.CacheMgmtInterceptor.updateStoreStatistics(CacheMgmtInterceptor.java:148)
at org.infinispan.interceptors.CacheMgmtInterceptor.visitPutKeyValueCommand(CacheMgmtInterceptor.java:134)
at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:71)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:110)
at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:73)
at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:32)
at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:71)
at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:333)
at org.infinispan.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1399)
at org.infinispan.CacheImpl.putInternal(CacheImpl.java:877)
at org.infinispan.CacheImpl.put(CacheImpl.java:869)
at org.infinispan.DecoratedCache.put(DecoratedCache.java:471)
at org.infinispan.persistence.manager.PersistenceManagerImpl.preloadKey(PersistenceManagerImpl.java:611)
... 43 more
{noformat}
--
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, 1 month