[JBoss JIRA] (ISPN-3335) JMX statistics for Queries partially doesn't work
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-3335?page=com.atlassian.jira.plugin.... ]
Adrian Nistor commented on ISPN-3335:
-------------------------------------
Created an issue on Hibernate Search: https://hibernate.atlassian.net/browse/HSEARCH-1461
For now we'll do our own workaround until Hibernate Search fixes it.
> JMX statistics for Queries partially doesn't work
> -------------------------------------------------
>
> Key: ISPN-3335
> URL: https://issues.jboss.org/browse/ISPN-3335
> Project: Infinispan
> Issue Type: Bug
> Components: Querying
> Affects Versions: 6.0.0.Alpha1
> Reporter: Anna Manukyan
> Assignee: Adrian Nistor
> Priority: Critical
> Labels: 620
> Fix For: 6.1.0.Final
>
> Attachments: QueryMBeanTest.java
>
>
> I was playing around with Query JMX statistics, and found out that there are several attributes like SearchQueryTotalTime are always 0 (this attr. represents the duration of query in nano-seconds), even though I'm running the infinispan query.
> The only attribute which is updated and returns proper value is StatisticsEnabled. Also the following operations work as expected:
> getNumberOfIndexedEntities(String entity)
> clear()
> I've tried also to retrieve the statistics using the following method:
> {code}
> Search.getSearchManager(cacheManager.getCache(CACHE_NAME)).getSearchFactory().getStatistics().getSearchQueryTotalTime()
> {code}
> and it returns the same results as if getting via JMX.
> You can find the whole running test attached.
> Best regards,
> Anna.
--
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, 7 months
[JBoss JIRA] (ISPN-3335) JMX statistics for Queries partially doesn't work
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-3335?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated ISPN-3335:
--------------------------------
Status: Pull Request Sent (was: Coding In Progress)
Git Pull Request: https://github.com/infinispan/infinispan/pull/2249
> JMX statistics for Queries partially doesn't work
> -------------------------------------------------
>
> Key: ISPN-3335
> URL: https://issues.jboss.org/browse/ISPN-3335
> Project: Infinispan
> Issue Type: Bug
> Components: Querying
> Affects Versions: 6.0.0.Alpha1
> Reporter: Anna Manukyan
> Assignee: Adrian Nistor
> Priority: Critical
> Labels: 620
> Fix For: 6.1.0.Final
>
> Attachments: QueryMBeanTest.java
>
>
> I was playing around with Query JMX statistics, and found out that there are several attributes like SearchQueryTotalTime are always 0 (this attr. represents the duration of query in nano-seconds), even though I'm running the infinispan query.
> The only attribute which is updated and returns proper value is StatisticsEnabled. Also the following operations work as expected:
> getNumberOfIndexedEntities(String entity)
> clear()
> I've tried also to retrieve the statistics using the following method:
> {code}
> Search.getSearchManager(cacheManager.getCache(CACHE_NAME)).getSearchFactory().getStatistics().getSearchQueryTotalTime()
> {code}
> and it returns the same results as if getting via JMX.
> You can find the whole running test attached.
> Best regards,
> Anna.
--
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, 7 months
[JBoss JIRA] (ISPN-3766) "containsKey" and "get" methods are not working properly with "putForExternalRead" during active transaction. WriteSkewException appears.
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-3766?page=com.atlassian.jira.plugin.... ]
William Burns commented on ISPN-3766:
-------------------------------------
If you notice the last paragraph from the user guid.
{quote}
Please note that putForExternalRead should never be used as a mechanism to update the cache with a new Person instance originating from application execution (i.e. from a transaction that modifies a Person’s address). When updating cached values, please use the standard put operation, otherwise the possibility of caching corrupt data is likely.
{quote}
So in this case you are doing as the first paragraph says and using PFER in a transaction that is modifying the same value. PFER's main purpose is to be used to update a cache irrespective of the current transaction that you invoked it in (which is why internally we start a new transaction as the Javadoc to PFER says on the [Cache class|https://docs.jboss.org/infinispan/6.0/apidocs/org/infinispan/Cache....]).
But yes if you are planning on updating the same value in the same transaction you should use a standard put.
> "containsKey" and "get" methods are not working properly with "putForExternalRead" during active transaction. WriteSkewException appears.
> -----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-3766
> URL: https://issues.jboss.org/browse/ISPN-3766
> Project: Infinispan
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 5.3.0.Final, 6.0.0.CR1, 6.0.0.Final
> Reporter: V L
> Assignee: Mircea Markus
> Attachments: InfinispanTest.java
>
>
> I'm not new with Infinispan, we use it from 5.3 version. Now I'm working on adding WriteSkew functional to our project, but unfortunately it's not working as we expected.
> We use infinispan like a cache for mongoDb data source, but this situation doesn't depends on data source vendor.
> The problem is that WriteSkewException is available in specific situation, here are steps for reproducing:
> 1) begin tx -> create an new element -> commit tx.
> 2) wait until cache expires. cache is empty now
> 3) being tx -> try to get element from cache, but it's not found -> load element from data source -> put it to the cache via putForExternalRead for read access outside of current transaction.
> 4) make some modification with element -> put element to cache -> commit tx -> WriteSkewException
> here is my log:
> TX BEGIN tx_status=6 thread=1
> PUT id=key1, tx_status=0, thread=1 cache_size=1, cache_ contains=key:key1, value:value
> TX COMMIT tx_status=0 thread=1
> TX BEGIN. tx_status=6, thread=1
> SIZE id=key1 tx_status=0, thread=1 cache_size=1 contains=key:key1, value:null
> PUT_FOR_EXTERNAL_READ id=key1, tx_status=0 thread=1 cache_size=1 cache_contains=key:key1, value:null
> PUT id=key1 tx_status=0 thread=1 cache_size=1 contains=key:key1, value:value
> TX COMMIT status=0 thread=1
> ISPN000005: Detected write skew on key [1]. Another process has changed the entry since we last read it! Unable to copy entry for update.
> Exception executing call org.infinispan.transaction.WriteSkewException: Detected write skew.
> I think the problem is in "get" method. When you invoke "get" method with key that not available in cache, infinispan create an "null" element in cache. This element won't be updated by putForExternalRead method (look at log above). If you skip "get" method invocation everithing will work fine. By the way, everithing is working fine if you skip "step 2" of the scenario.
> I use workaround for this situation. I check if element exist in the cache not by "containsKey" or "get" method but via cache.keySet().contains(key)
> This works ok
> I'm looking forward for you comments, maybe I'm doing something wrong.
> Thanks
--
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, 7 months
[JBoss JIRA] (ISPN-3354) Multiple events on the local node with Infinispan 5.3.0-final
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3354?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3354:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> 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, 7 months
[JBoss JIRA] (ISPN-3722) State transfer must be enabled for Lucene Directory if clustered caches are used
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3722?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3722:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> State transfer must be enabled for Lucene Directory if clustered caches are used
> --------------------------------------------------------------------------------
>
> Key: ISPN-3722
> URL: https://issues.jboss.org/browse/ISPN-3722
> Project: Infinispan
> Issue Type: Bug
> Components: Lucene Directory
> Affects Versions: 6.0.0.CR1
> Reporter: Pedro Ruivo
> Assignee: Pedro Ruivo
> Fix For: 6.1.0.Final
>
>
> take a look at the following code:
> {code:java}
> public Set<String> getFileList() {
> Set<String> fileList = (Set<String>) cache.get(fileListCacheKey);
> if (fileList == null) {
> fileList = new ConcurrentHashSet<String>();
> Set<String> prev = (Set<String>) cache.putIfAbsent(fileListCacheKey, fileList);
> if ( prev != null ) {
> fileList = prev;
> }
> }
> return fileList;
> }
> {code}
> when it requests the file list, the joiner does not have the data locally and it tries to do a putIfAbsent with an empty set. However, when it reaches the primary owner (if not changed), it will return the current file list.
> After, it tries to read the files returned in the set and it cannot find it, throwing an IOException -- "Read past EOF"
> A validation should be made in order to not allow clustered caches without state transfer.
--
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, 7 months
[JBoss JIRA] (ISPN-3777) ThreadLocal in AbstractInvocationContextContainer is leaking instances of LocalTxInvocationContext
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/ISPN-3777?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero updated ISPN-3777:
----------------------------------
Priority: Critical (was: Major)
> 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: Mircea Markus
> 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, 7 months
[JBoss JIRA] (ISPN-3777) ThreadLocal in AbstractInvocationContextContainer is leaking instances of LocalTxInvocationContext
by Ales Justin (JIRA)
[ https://issues.jboss.org/browse/ISPN-3777?page=com.atlassian.jira.plugin.... ]
Ales Justin commented on ISPN-3777:
-----------------------------------
Why don't you simply apply
ICC:: void clearThreadLocal();
after every
LocalTxInvocationContext ctx = icc.createTxInvocationContext();
usage.
But instead "hide" this in some Interceptor.
(where I usually see a few lines of code always being invoked before Invoker::invoke,
hence no wonder this kind of stuff starts to leak)
> 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: Mircea Markus
>
> 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, 7 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:
------------------------------
Description:
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}
was:
When running CapeDwarf log tests on Infinispan 6.0.0 & Wildfly, we're seeing lots of retained instances of LocalTxInvocationContext.
So far, 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}
> 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: Mircea Markus
>
> 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, 7 months
[JBoss JIRA] (ISPN-3777) ThreadLocal in AbstractInvocationContextContainer is leaking instances of LocalTxInvocationContext
by Marko Lukša (JIRA)
Marko Lukša created ISPN-3777:
---------------------------------
Summary: 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: Mircea Markus
When running CapeDwarf log tests on Infinispan 6.0.0 & Wildfly, we're seeing lots of retained instances of LocalTxInvocationContext.
So far, 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, 7 months
[JBoss JIRA] (ISPN-3770) Incorrect Content-Type header when putting object via REST and get with different Accept
by Jiří Holuša (JIRA)
[ https://issues.jboss.org/browse/ISPN-3770?page=com.atlassian.jira.plugin.... ]
Jiří Holuša commented on ISPN-3770:
-----------------------------------
Ok, thanks for clarification. Let's see what ttarrant says on github about changing this to feature request.
> Incorrect Content-Type header when putting object via REST and get with different Accept
> ----------------------------------------------------------------------------------------
>
> Key: ISPN-3770
> URL: https://issues.jboss.org/browse/ISPN-3770
> Project: Infinispan
> Issue Type: Bug
> Components: Server
> Reporter: Jiří Holuša
> Assignee: Mircea Markus
>
> When putting serialized object via REST post and then getting it back with different Accept header (for example application/json), the retrieved data has still the "creation-time" Content-Type and data doesn't change in any way.
> I would expect retrieving nice json structure for instace.
> Code snippet:
> {code}
> public void testCustomObjectGetAcceptJSONAndXML() throws Exception{
> String fullPathKeyA = fullPathKey(KEY_A);
> TestSerializable object = new TestSerializable("CONTENT");
> ByteArrayOutputStream bout = new ByteArrayOutputStream();
> ObjectOutputStream oo = new ObjectOutputStream(bout);
> oo.writeObject(object);
> oo.flush();
> oo.close();
> byte[] byteData = bout.toByteArray();
> post(fullPathKeyA, byteData, "application/x-java-serialized-object");
> HttpResponse getJson = get(fullPathKeyA, null, HttpServletResponse.SC_OK, true, "Accept", "application/json");
> assertTrue(getJson.getHeaders("Content-type")[0].getValue().contains("application/json")); //this assertion fails
> HttpResponse getXml = get(fullPathKeyA, null, HttpServletResponse.SC_OK, true, "Accept", "application/xml");
> assertTrue(getXml.getHeaders("Content-type")[0].getValue().contains("application/xml")); //this assertion fails
> }
> {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, 7 months