[JBoss JIRA] (ISPN-3316) CDI Cache interceptor tests are failing while running in EAP container
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3316?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3316:
-----------------------------------------------
Vojtech Juranek <vjuranek(a)redhat.com> changed the Status of [bug 1024410|https://bugzilla.redhat.com/show_bug.cgi?id=1024410] from ON_QA to CLOSED
> CDI Cache interceptor tests are failing while running in EAP container
> ----------------------------------------------------------------------
>
> Key: ISPN-3316
> URL: https://issues.jboss.org/browse/ISPN-3316
> Project: Infinispan
> Issue Type: Bug
> Components: CDI integration
> Affects Versions: 5.3.0.Final, 6.0.0.Final
> Reporter: Anna Manukyan
> Assignee: Galder Zamarreño
> Labels: 620
> Fix For: 6.1.0.Final
>
>
> While migration of the CDI related tests to work under EAP container (at the moment using 6.0.GA), it was found that the tests related to interceptors are failing. The issue relates to
> org.infinispan.cdi.test.interceptor.CachePutInterceptorTest, org.infinispan.cdi.test.interceptor.CacheRemoveAllInterceptorTest, org.infinispan.cdi.test.interceptor.CacheRemoveInterceptorTest, org.infinispan.cdi.test.interceptor.CacheResultInterceptorTest.
> The failure relates to assertions. The thing is that all actions which are done using javax.cache.cache-api annotations, work properly (I've added some logs e.g. in CachePutInterceptor, and it shows that the data is put to the cache properly).
> But later when the test wants to verify that the data is really put to the data, retrieves the cache from the injected CacheContainer, the cache is empty - the data is not there.
> The issue appeared since the latest changes to the Infinispan-CDI module, and split to infinispan-jcache module. For the previous version, the tests are passed under EAP container.
> The example above was given for the CachePutInterceptorTest, but the same refers to the rest of them.
> The git repo for the sources, will be provided later.
--
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
[JBoss JIRA] (ISPN-3795) QueryInterceptor incorrectly relies on the return value of a RemoveCommand
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/ISPN-3795?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero commented on ISPN-3795:
---------------------------------------
How do I trigger the boolean return type?
> QueryInterceptor incorrectly relies on the return value of a RemoveCommand
> --------------------------------------------------------------------------
>
> Key: ISPN-3795
> URL: https://issues.jboss.org/browse/ISPN-3795
> Project: Infinispan
> Issue Type: Bug
> Components: Querying
> Affects Versions: 6.0.0.Final
> Reporter: Dan Berindei
> Assignee: Sanne Grinovero
> Fix For: 7.0.0.Final
>
>
> QueryInterceptor uses the return value from RemoveCommand/ReplaceCommand to remove the value from the index.
> But both RemoveCommand and ReplaceCommand have a variant with an expected value parameter, and this variant return a boolean value instead of the removed/replaced value. In that case, the previous value won't be removed from the index.
> QueryInterceptor should probably use the previous value from the context entries to update the index instead.
--
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
[JBoss JIRA] (ISPN-3537) Custom interceptor with Position.LAST set programmatically doesn't work
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3537?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3537:
-----------------------------------------------
Jiri Holusa <jholusa(a)redhat.com> changed the Status of [bug 1024414|https://bugzilla.redhat.com/show_bug.cgi?id=1024414] from ON_QA to VERIFIED
> Custom interceptor with Position.LAST set programmatically doesn't work
> -----------------------------------------------------------------------
>
> Key: ISPN-3537
> URL: https://issues.jboss.org/browse/ISPN-3537
> Project: Infinispan
> Issue Type: Bug
> Components: Configuration
> Affects Versions: 6.0.0.Beta1
> Reporter: Jiří Holuša
> Assignee: Mircea Markus
> Labels: 620
> Fix For: 6.1.0.Final
>
>
> When configuring cache programmatically, adding a custom interceptor with position set to Position.LAST cause not calling this interceptor.
> Code sample:
> {code:borderStyle=solid}
> EmbeddedCacheManager manager = new DefaultCacheManager();
> Configuration c2 = new ConfigurationBuilder()
> .customInterceptors()
> .addInterceptor() .position(InterceptorConfiguration.Position.LAST).interceptor(new MyInterceptor())
> .build();
> manager.defineConfiguration("interceptors", c2);
> Cache<String, String> cache = manager.getCache("interceptors");
> cache.put("hello", "world");
> {code}
> MyInterceptor is very simple, reacting to all events. When changing to Position.FIRST, everything works fine. Also tried two/three interceptors, various combinations, but always with same result - when position set to Position.LAST, interceptors is not called.
> Note that no problem when setting by index().
--
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
[JBoss JIRA] (ISPN-3796) ClusteredQueryDslConditionsTest fails randomly
by Adrian Nistor (JIRA)
Adrian Nistor created ISPN-3796:
-----------------------------------
Summary: ClusteredQueryDslConditionsTest fails randomly
Key: ISPN-3796
URL: https://issues.jboss.org/browse/ISPN-3796
Project: Infinispan
Issue Type: Bug
Components: Querying, Test Suite
Affects Versions: 6.0.0.Final
Reporter: Adrian Nistor
Assignee: Adrian Nistor
See stacktrace:
{noformat}
testSampleDomainQuery16(org.infinispan.query.dsl.embedded.ClusteredQueryDslConditionsTest) Time elapsed: 0.143 sec <<< FAILURE!
org.infinispan.remoting.RemoteException: ISPN000217: Received exception from ClusteredQueryDslConditionsTest-NodeDE-6251, see cause for remote stack trace
at org.infinispan.remoting.transport.AbstractTransport.checkResponse(AbstractTransport.java:41)
at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.processSingleCall(CommandAwareRpcDispatcher.java:362)
at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:167)
at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:521)
at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:281)
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:233)
at org.infinispan.query.backend.QueryInterceptor.performSearchWork(QueryInterceptor.java:227)
at org.infinispan.query.backend.QueryInterceptor.updateIndexes(QueryInterceptor.java:221)
at org.infinispan.query.backend.QueryInterceptor.processPutKeyValueCommand(QueryInterceptor.java:518)
at org.infinispan.query.backend.QueryInterceptor.visitPutKeyValueCommand(QueryInterceptor.java:164)
at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitPutKeyValueCommand(AbstractLockingInterceptor.java:45)
at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
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:62)
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:62)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
at org.infinispan.statetransfer.StateTransferInterceptor.handleNonTxWriteCommand(StateTransferInterceptor.java:214)
at org.infinispan.statetransfer.StateTransferInterceptor.visitPutKeyValueCommand(StateTransferInterceptor.java:136)
at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
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:62)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:106)
at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:70)
at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:32)
at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:327)
at org.infinispan.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1296)
at org.infinispan.CacheImpl.putInternal(CacheImpl.java:869)
at org.infinispan.CacheImpl.put(CacheImpl.java:861)
at org.infinispan.CacheImpl.put(CacheImpl.java:1349)
at org.infinispan.CacheImpl.put(CacheImpl.java:206)
at org.infinispan.query.dsl.embedded.ClusteredQueryDslConditionsTest.testSampleDomainQuery16(ClusteredQueryDslConditionsTest.java:1059)
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:724)
Caused by: org.hibernate.search.SearchException: Error applying updates to the Lucene index
at org.hibernate.search.backend.impl.lucene.LuceneBackendQueueProcessor.applyWork(LuceneBackendQueueProcessor.java:106)
at org.infinispan.query.indexmanager.MasterSwitchDelegatingQueueProcessor.applyWork(MasterSwitchDelegatingQueueProcessor.java:49)
at org.hibernate.search.indexes.impl.DirectoryBasedIndexManager.performOperations(DirectoryBasedIndexManager.java:126)
at org.infinispan.query.indexmanager.IndexUpdateCommand.perform(IndexUpdateCommand.java:53)
at org.infinispan.remoting.InboundInvocationHandlerImpl.handleInternal(InboundInvocationHandlerImpl.java:95)
at org.infinispan.remoting.InboundInvocationHandlerImpl.access$000(InboundInvocationHandlerImpl.java:50)
at org.infinispan.remoting.InboundInvocationHandlerImpl$2.run(InboundInvocationHandlerImpl.java:172)
... 3 more
Caused by: java.lang.AssertionError: file _b.fdt does not exist
at org.apache.lucene.index.IndexWriter.filesExist(IndexWriter.java:4492)
at org.apache.lucene.index.IndexWriter.startCommit(IndexWriter.java:4543)
at org.apache.lucene.index.IndexWriter.prepareCommit(IndexWriter.java:3414)
at org.apache.lucene.index.IndexWriter.commitInternal(IndexWriter.java:3485)
at org.apache.lucene.index.IndexWriter.commit(IndexWriter.java:3467)
at org.apache.lucene.index.IndexWriter.commit(IndexWriter.java:3451)
at org.hibernate.search.backend.impl.lucene.IndexWriterHolder.commitIndexWriter(IndexWriterHolder.java:158)
at org.hibernate.search.backend.impl.lucene.IndexWriterHolder.commitIndexWriter(IndexWriterHolder.java:171)
at org.hibernate.search.backend.impl.lucene.ExclusiveIndexWorkspaceImpl.afterTransactionApplied(ExclusiveIndexWorkspaceImpl.java:45)
at org.hibernate.search.backend.impl.lucene.LuceneBackendQueueTask.applyUpdates(LuceneBackendQueueTask.java:124)
at org.hibernate.search.backend.impl.lucene.LuceneBackendQueueTask.run(LuceneBackendQueueTask.java:67)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
... 3 more
Results :
Failed tests:
ClusteredQueryDslConditionsTest.testSampleDomainQuery16:1059 » Remote ISPN0002...
Tests run: 1036, Failures: 1, Errors: 0, Skipped: 0
{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
[JBoss JIRA] (ISPN-3354) Multiple events on the local node with Infinispan 5.3.0-final
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3354?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3354:
-----------------------------------------------
Martin Gencur <mgencur(a)redhat.com> changed the Status of [bug 1024942|https://bugzilla.redhat.com/show_bug.cgi?id=1024942] from ON_QA to VERIFIED
> Multiple events on the local node with Infinispan 5.3.0-final
> -------------------------------------------------------------
>
> Key: ISPN-3354
> URL: https://issues.jboss.org/browse/ISPN-3354
> Project: Infinispan
> Issue Type: Bug
> Components: Listeners
> Affects Versions: 5.3.0.Final
> Reporter: Luca Zenti
> Assignee: Pedro Ruivo
> Priority: Critical
> Labels: 620
> Fix For: 6.1.0.Final
>
> Attachments: TestInfinispanDuplicatedEvents.java
>
>
> After upgrading to Infinispan 5.3.0-final I found a strange "intermittent" problem in my application. Digging a bit deeper, I found out it is due to CacheEntry events raised twice for some keys on the local node (the node where the cache operation is invoked).
> I was able to reproduce the problem and I wrote the attached test case.
> The problem happens regardless of the cluster mode, but only with non-transactional caches. I think this is due to the fact that with transactional caches the events are raised on commit.
> Also, my application used to work with an interceptor rather than an event listener, so I actually found the problem when I saw my interceptor being occasionally executed 3 times with 2 nodes.
> I'm not sure whether the command and the chain of interceptor is really meant to be executed twice on the local node, but the consequent behaviour on the events sounds like a bug.
--
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
[JBoss JIRA] (ISPN-3777) ThreadLocal in AbstractInvocationContextContainer is leaking instances of LocalTxInvocationContext
by Marko Lukša (JIRA)
[ https://issues.jboss.org/browse/ISPN-3777?page=com.atlassian.jira.plugin.... ]
Marko Lukša updated ISPN-3777:
------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/2263
Pull request is at https://github.com/infinispan/infinispan/pull/2263
The ThreadLocal cleanup is no longer performed by the interceptor. It is now performed inside {{finally}}.
> ThreadLocal in AbstractInvocationContextContainer is leaking instances of LocalTxInvocationContext
> --------------------------------------------------------------------------------------------------
>
> Key: ISPN-3777
> URL: https://issues.jboss.org/browse/ISPN-3777
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 6.0.0.Final
> Reporter: Marko Lukša
> Assignee: Marko Lukša
> Priority: Critical
>
> When running CapeDwarf log tests on Infinispan 6.0.0 & Wildfly, we're seeing lots of retained instances of LocalTxInvocationContext.
> So far I've seen the instances that are not removed are created at the following two points:
> {code}
> java.lang.Exception: Creation stack
> at org.infinispan.context.impl.LocalTxInvocationContext.<init>(LocalTxInvocationContext.java:42)
> at org.infinispan.context.TransactionalInvocationContextContainer.createInvocationContext(TransactionalInvocationContextContainer.java:100)
> at org.infinispan.CacheImpl.getInvocationContext(CacheImpl.java:615)
> at org.infinispan.CacheImpl.getInvocationContextWithImplicitTransaction(CacheImpl.java:599)
> at org.infinispan.CacheImpl.getInvocationContextWithImplicitTransactionForAsyncOps(CacheImpl.java:569)
> at org.infinispan.CacheImpl.putAsync(CacheImpl.java:996)
> at org.infinispan.DecoratedCache.putAsync(DecoratedCache.java:238)
> at org.infinispan.AbstractDelegatingCache.putAsync(AbstractDelegatingCache.java:131)
> at org.jboss.capedwarf.log.CapedwarfLogService$AsyncLogWriter.put(CapedwarfLogService.java:378)
> at org.jboss.capedwarf.log.CapedwarfLogService.requestFinished(CapedwarfLogService.java:348)
> at sun.reflect.GeneratedMethodAccessor74.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.jboss.capedwarf.aspects.proxy.AspectContext.proceed(AspectContext.java:47)
> at org.jboss.capedwarf.aspects.DisableSocketsAspect.invoke(DisableSocketsAspect.java:43)
> at org.jboss.capedwarf.aspects.proxy.AspectWrapper.invoke(AspectWrapper.java:50)
> at org.jboss.capedwarf.aspects.proxy.AspectContext.proceed(AspectContext.java:52)
> at org.jboss.capedwarf.aspects.GlobalTimeLimitAspect.invoke(GlobalTimeLimitAspect.java:44)
> at org.jboss.capedwarf.aspects.proxy.AspectWrapper.invoke(AspectWrapper.java:50)
> at org.jboss.capedwarf.aspects.proxy.AspectContext.proceed(AspectContext.java:52)
> at org.jboss.capedwarf.aspects.proxy.AspectHandler.invoke(AspectHandler.java:60)
> at org.jboss.capedwarf.log.ExposedLogService_$$_jvst183_0.requestFinished(ExposedLogService_$$_jvst183_0.java)
> at org.jboss.capedwarf.appidentity.GAEListener.requestDestroyed(GAEListener.java:125)
> at io.undertow.servlet.core.ApplicationListeners.requestDestroyed(ApplicationListeners.java:225)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:282)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:226)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:72)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:145)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:139)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:638)
> 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)
> {code}
> and
> {code}
> java.lang.Exception: Creation stack
> at org.infinispan.context.impl.LocalTxInvocationContext.<init>(LocalTxInvocationContext.java:42)
> at org.infinispan.context.TransactionalInvocationContextContainer.createTxInvocationContext(TransactionalInvocationContextContainer.java:110)
> at org.infinispan.transaction.TransactionCoordinator.commit(TransactionCoordinator.java:145)
> at org.infinispan.transaction.synchronization.SynchronizationAdapter.afterCompletion(SynchronizationAdapter.java:58)
> at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.afterCompletion(SynchronizationImple.java:96)
> at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.afterCompletion(TwoPhaseCoordinator.java:532)
> at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:101)
> at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1170)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126)
> at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75)
> at org.infinispan.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1306)
> at org.infinispan.CacheImpl.putInternal(CacheImpl.java:869)
> at org.infinispan.CacheImpl.put(CacheImpl.java:861)
> at org.infinispan.DecoratedCache.put(DecoratedCache.java:401)
> at org.infinispan.AbstractDelegatingCache.put(AbstractDelegatingCache.java:276)
> at org.jboss.capedwarf.log.CapedwarfLogService$SyncLogWriter.put(CapedwarfLogService.java:390)
> at org.jboss.capedwarf.log.CapedwarfLogService.requestFinished(CapedwarfLogService.java:348)
> at sun.reflect.GeneratedMethodAccessor70.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.jboss.capedwarf.aspects.proxy.AspectContext.proceed(AspectContext.java:47)
> at org.jboss.capedwarf.aspects.DisableSocketsAspect.invoke(DisableSocketsAspect.java:43)
> at org.jboss.capedwarf.aspects.proxy.AspectWrapper.invoke(AspectWrapper.java:50)
> at org.jboss.capedwarf.aspects.proxy.AspectContext.proceed(AspectContext.java:52)
> at org.jboss.capedwarf.aspects.GlobalTimeLimitAspect.invoke(GlobalTimeLimitAspect.java:44)
> at org.jboss.capedwarf.aspects.proxy.AspectWrapper.invoke(AspectWrapper.java:50)
> at org.jboss.capedwarf.aspects.proxy.AspectContext.proceed(AspectContext.java:52)
> at org.jboss.capedwarf.aspects.proxy.AspectHandler.invoke(AspectHandler.java:60)
> at org.jboss.capedwarf.log.ExposedLogService_$$_jvst8b1_0.requestFinished(ExposedLogService_$$_jvst8b1_0.java)
> at org.jboss.capedwarf.appidentity.GAEListener.requestDestroyed(GAEListener.java:125)
> at io.undertow.servlet.core.ApplicationListeners.requestDestroyed(ApplicationListeners.java:225)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:282)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:226)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:72)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:145)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:139)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:638)
> 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)
> {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
[JBoss JIRA] (ISPN-3777) ThreadLocal in AbstractInvocationContextContainer is leaking instances of LocalTxInvocationContext
by Marko Lukša (JIRA)
[ https://issues.jboss.org/browse/ISPN-3777?page=com.atlassian.jira.plugin.... ]
Marko Lukša reassigned ISPN-3777:
---------------------------------
Assignee: Marko Lukša (was: Mircea Markus)
> ThreadLocal in AbstractInvocationContextContainer is leaking instances of LocalTxInvocationContext
> --------------------------------------------------------------------------------------------------
>
> Key: ISPN-3777
> URL: https://issues.jboss.org/browse/ISPN-3777
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 6.0.0.Final
> Reporter: Marko Lukša
> Assignee: Marko Lukša
> Priority: Critical
>
> When running CapeDwarf log tests on Infinispan 6.0.0 & Wildfly, we're seeing lots of retained instances of LocalTxInvocationContext.
> So far I've seen the instances that are not removed are created at the following two points:
> {code}
> java.lang.Exception: Creation stack
> at org.infinispan.context.impl.LocalTxInvocationContext.<init>(LocalTxInvocationContext.java:42)
> at org.infinispan.context.TransactionalInvocationContextContainer.createInvocationContext(TransactionalInvocationContextContainer.java:100)
> at org.infinispan.CacheImpl.getInvocationContext(CacheImpl.java:615)
> at org.infinispan.CacheImpl.getInvocationContextWithImplicitTransaction(CacheImpl.java:599)
> at org.infinispan.CacheImpl.getInvocationContextWithImplicitTransactionForAsyncOps(CacheImpl.java:569)
> at org.infinispan.CacheImpl.putAsync(CacheImpl.java:996)
> at org.infinispan.DecoratedCache.putAsync(DecoratedCache.java:238)
> at org.infinispan.AbstractDelegatingCache.putAsync(AbstractDelegatingCache.java:131)
> at org.jboss.capedwarf.log.CapedwarfLogService$AsyncLogWriter.put(CapedwarfLogService.java:378)
> at org.jboss.capedwarf.log.CapedwarfLogService.requestFinished(CapedwarfLogService.java:348)
> at sun.reflect.GeneratedMethodAccessor74.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.jboss.capedwarf.aspects.proxy.AspectContext.proceed(AspectContext.java:47)
> at org.jboss.capedwarf.aspects.DisableSocketsAspect.invoke(DisableSocketsAspect.java:43)
> at org.jboss.capedwarf.aspects.proxy.AspectWrapper.invoke(AspectWrapper.java:50)
> at org.jboss.capedwarf.aspects.proxy.AspectContext.proceed(AspectContext.java:52)
> at org.jboss.capedwarf.aspects.GlobalTimeLimitAspect.invoke(GlobalTimeLimitAspect.java:44)
> at org.jboss.capedwarf.aspects.proxy.AspectWrapper.invoke(AspectWrapper.java:50)
> at org.jboss.capedwarf.aspects.proxy.AspectContext.proceed(AspectContext.java:52)
> at org.jboss.capedwarf.aspects.proxy.AspectHandler.invoke(AspectHandler.java:60)
> at org.jboss.capedwarf.log.ExposedLogService_$$_jvst183_0.requestFinished(ExposedLogService_$$_jvst183_0.java)
> at org.jboss.capedwarf.appidentity.GAEListener.requestDestroyed(GAEListener.java:125)
> at io.undertow.servlet.core.ApplicationListeners.requestDestroyed(ApplicationListeners.java:225)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:282)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:226)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:72)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:145)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:139)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:638)
> 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)
> {code}
> and
> {code}
> java.lang.Exception: Creation stack
> at org.infinispan.context.impl.LocalTxInvocationContext.<init>(LocalTxInvocationContext.java:42)
> at org.infinispan.context.TransactionalInvocationContextContainer.createTxInvocationContext(TransactionalInvocationContextContainer.java:110)
> at org.infinispan.transaction.TransactionCoordinator.commit(TransactionCoordinator.java:145)
> at org.infinispan.transaction.synchronization.SynchronizationAdapter.afterCompletion(SynchronizationAdapter.java:58)
> at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.afterCompletion(SynchronizationImple.java:96)
> at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.afterCompletion(TwoPhaseCoordinator.java:532)
> at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:101)
> at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1170)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126)
> at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75)
> at org.infinispan.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1306)
> at org.infinispan.CacheImpl.putInternal(CacheImpl.java:869)
> at org.infinispan.CacheImpl.put(CacheImpl.java:861)
> at org.infinispan.DecoratedCache.put(DecoratedCache.java:401)
> at org.infinispan.AbstractDelegatingCache.put(AbstractDelegatingCache.java:276)
> at org.jboss.capedwarf.log.CapedwarfLogService$SyncLogWriter.put(CapedwarfLogService.java:390)
> at org.jboss.capedwarf.log.CapedwarfLogService.requestFinished(CapedwarfLogService.java:348)
> at sun.reflect.GeneratedMethodAccessor70.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.jboss.capedwarf.aspects.proxy.AspectContext.proceed(AspectContext.java:47)
> at org.jboss.capedwarf.aspects.DisableSocketsAspect.invoke(DisableSocketsAspect.java:43)
> at org.jboss.capedwarf.aspects.proxy.AspectWrapper.invoke(AspectWrapper.java:50)
> at org.jboss.capedwarf.aspects.proxy.AspectContext.proceed(AspectContext.java:52)
> at org.jboss.capedwarf.aspects.GlobalTimeLimitAspect.invoke(GlobalTimeLimitAspect.java:44)
> at org.jboss.capedwarf.aspects.proxy.AspectWrapper.invoke(AspectWrapper.java:50)
> at org.jboss.capedwarf.aspects.proxy.AspectContext.proceed(AspectContext.java:52)
> at org.jboss.capedwarf.aspects.proxy.AspectHandler.invoke(AspectHandler.java:60)
> at org.jboss.capedwarf.log.ExposedLogService_$$_jvst8b1_0.requestFinished(ExposedLogService_$$_jvst8b1_0.java)
> at org.jboss.capedwarf.appidentity.GAEListener.requestDestroyed(GAEListener.java:125)
> at io.undertow.servlet.core.ApplicationListeners.requestDestroyed(ApplicationListeners.java:225)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:282)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:226)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:72)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:145)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:139)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:638)
> 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)
> {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
[JBoss JIRA] (ISPN-3759) org.infinispan.cli.interpreter.UpgradeTest.testSynchronization fails on all environments
by Vojtech Juranek (JIRA)
[ https://issues.jboss.org/browse/ISPN-3759?page=com.atlassian.jira.plugin.... ]
Vojtech Juranek commented on ISPN-3759:
---------------------------------------
Hi,
i believe this duplicates ISPN-3712, which seems to be fixed by
https://github.com/infinispan/infinispan-server/pull/202
and
https://github.com/infinispan/infinispan/pull/2260
> org.infinispan.cli.interpreter.UpgradeTest.testSynchronization fails on all environments
> ----------------------------------------------------------------------------------------
>
> Key: ISPN-3759
> URL: https://issues.jboss.org/browse/ISPN-3759
> Project: Infinispan
> Issue Type: Bug
> Components: CLI
> Affects Versions: 6.0.0.Final
> Environment: Test fails on all environments
> Reporter: Vitalii Chepeliuk
> Assignee: Mircea Markus
> Labels: testsuite_stability
>
> There is a problem with ByteArrayKey class and we get
> java.lang.AssertionError: org/infinispan/util/ByteArrayKey
> at org.testng.AssertJUnit.fail(AssertJUnit.java:59)
> at org.testng.AssertJUnit.assertTrue(AssertJUnit.java:24)
> at org.testng.AssertJUnit.assertFalse(AssertJUnit.java:41)
> at org.infinispan.cli.interpreter.UpgradeTest.checkNoErrors(UpgradeTest.java:101)
> at org.infinispan.cli.interpreter.UpgradeTest.testSynchronization(UpgradeTest.java:87)
> In infinispan-cachestore-remote/pom.xml
> <dependency>
> <groupId>${project.groupId}</groupId>
> <artifactId>infinispan-adaptor52x</artifactId>
> <optional>true</optional> <<< this dependency is optional
> </dependency>
> So when test is running there is no ByteArrayKey under classpath and it fails
--
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
[JBoss JIRA] (ISPN-3795) QueryInterceptor incorrectly relies on the return value of a RemoveCommand
by Dan Berindei (JIRA)
Dan Berindei created ISPN-3795:
----------------------------------
Summary: QueryInterceptor incorrectly relies on the return value of a RemoveCommand
Key: ISPN-3795
URL: https://issues.jboss.org/browse/ISPN-3795
Project: Infinispan
Issue Type: Bug
Components: Querying
Affects Versions: 6.0.0.Final
Reporter: Dan Berindei
Assignee: Sanne Grinovero
Fix For: 7.0.0.Final
QueryInterceptor uses the return value from RemoveCommand/ReplaceCommand to remove the value from the index.
But both RemoveCommand and ReplaceCommand have a variant with an expected value parameter, and this variant return a boolean value instead of the removed/replaced value. In that case, the previous value won't be removed from the index.
QueryInterceptor should probably use the previous value from the context entries to update the index instead.
--
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
[JBoss JIRA] (ISPN-3786) REST server is treating timeToLiveSeconds=0 inconsistently
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-3786?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño commented on ISPN-3786:
----------------------------------------
Fix integrated in infinispan/infinispan. More tests still need adding to server.
> REST server is treating timeToLiveSeconds=0 inconsistently
> ----------------------------------------------------------
>
> Key: ISPN-3786
> URL: https://issues.jboss.org/browse/ISPN-3786
> Project: Infinispan
> Issue Type: Bug
> Components: Remote protocols
> Reporter: Jakub Markos
> Assignee: Galder Zamarreño
>
> The REST server currently handles 0 values for timeToLiveSeconds and maxIdleTimeSeconds like this:
> ||timeToLiveSeconds||maxIdleTimeSeconds||used lifespan||used maxIdle||
> |0|0|default from config|default from config|
> |nothing or >0|0|whatever came or -1|default from config|
> |0|nothing or >0|literally 0(*entry expires immediately*)|whatever came or -1|
> After discussion with Galder, the last line doesn't really make sense, and the better way would be to use default for timeToLive as well.
--
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