[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
10 years, 6 months
[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
10 years, 6 months
[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
10 years, 6 months
[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
10 years, 6 months
[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
10 years, 6 months
[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
10 years, 6 months
[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
10 years, 6 months
[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
10 years, 6 months
[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
10 years, 6 months
[JBoss JIRA] (ISPN-3767) MassIndexer breaks search feature with one node cluster
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3767?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3767:
-----------------------------------------------
Sanne Grinovero <sanne(a)redhat.com> changed the Status of [bug 1038720|https://bugzilla.redhat.com/show_bug.cgi?id=1038720] from NEW to POST
> MassIndexer breaks search feature with one node cluster
> -------------------------------------------------------
>
> Key: ISPN-3767
> URL: https://issues.jboss.org/browse/ISPN-3767
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.2.4.Final
> Reporter: Romain Pelisse
> Assignee: Adrian Nistor
> Fix For: 6.1.0.Final
>
>
> Hi,
> Trying to cope with the extreme slowliness of put() operation with indexing [1], I've tried to use the MassIndexer, to create the index AFTER adding all the data in the grid. This actually works pretty well, but, when running in a "single node" grid, it "breaks" the search, which always returns 0 result to any kind of query.
> I've modified one of the test suite of InfiniSpan to reproduce the issue:
> https://github.com/rpelisse/infinispan/tree/mass-indexer-breaks-search-wi...
> Once this branch is checked out, just run :
> $ cd ./query
> $ mvn clean -Dtest=org.infinispan.query.distributed.DistributedMassIndexingTest test
> Note: MassIndexer being implemented using the Map/Reduce algorithm, it requires to run within a cluster (ie several instances of ISPN).
> [1] http://stackoverflow.com/questions/10090361/infinispan-very-slow-for-load...
> If run within a single node cluster, the MassIndexer
--
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
10 years, 6 months