[JBoss JIRA] (ISPN-3085) ExpiryTest intermittent failure
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-3085?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-3085:
-------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> ExpiryTest intermittent failure
> -------------------------------
>
> Key: ISPN-3085
> URL: https://issues.jboss.org/browse/ISPN-3085
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 5.2.6.Final
> Reporter: Mircea Markus
> Assignee: Mircea Markus
> Fix For: 5.3.0.Beta2
>
>
> java.lang.NullPointerException
> at org.infinispan.expiry.ExpiryTest.testLifespanExpiryInPutIfAbsent(ExpiryTest.java:153)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> 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$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
> at java.lang.Thread.run(Thread.java:662)
--
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
11 years, 2 months
[JBoss JIRA] (ISPN-3089) The first write to a joiner in invalidation mode can be ignored
by Dan Berindei (JIRA)
Dan Berindei created ISPN-3089:
----------------------------------
Summary: The first write to a joiner in invalidation mode can be ignored
Key: ISPN-3089
URL: https://issues.jboss.org/browse/ISPN-3089
Project: Infinispan
Issue Type: Bug
Components: State transfer
Affects Versions: 5.3.0.Beta1, 5.2.6.Final
Reporter: Dan Berindei
Assignee: Dan Berindei
Fix For: 5.3.0.Final
In invalidation mode we don't wait for the initial state transfer to finish, or even for the joiner to become a member in the "write" CH, before returning to the user from {{getCache()}}.
Writes to the joiner before it becomes a member of the write CH are not committed to the local cache, because of a check in {{EntryWrappingInterceptor.shouldWrap()}}. So it's possible for the joiner to ignore the first write completely.
If {{StateTransferConfigurationBuilder}} enabled {{waitForInitialTransfer}} by default in invalidation mode, like it does in distributed/replicated mode, this wouldn't happen.
The fact that it will still be possible for the user to disable {{waitForInitialTransfer}} manually shouldn't be a problem, because in invalidation mode the user should expect values to be invalidated at any time. This is just about improving the default configuration.
--
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
11 years, 2 months
[JBoss JIRA] (ISPN-3061) Total Order Tweaks
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-3061?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-3061:
-------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 5.3.0.Beta2
Resolution: Done
> Total Order Tweaks
> ------------------
>
> Key: ISPN-3061
> URL: https://issues.jboss.org/browse/ISPN-3061
> Project: Infinispan
> Issue Type: Enhancement
> Components: Transactions
> Affects Versions: 5.3.0.Alpha1
> Reporter: Pedro Ruivo
> Assignee: Pedro Ruivo
> Fix For: 5.3.0.Beta2, 5.3.0.Final
>
>
> with total order, it should check for PrepareCommand ready to be validated after it sends back the response for Prepare/Commit/RollbackCommand. Check for it before is bad because the thread that performs the check may pick other PrepareCommand for validation if the executor service has no available threads. This can lead to higher response time or, in the worst scenario, to timeouts in the TransactionCoordinator.
--
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
11 years, 2 months
[JBoss JIRA] (ISPN-3086) Infinite loop when creating more than two Distributed Cache nodes
by Balazs Zsoldos (JIRA)
[ https://issues.jboss.org/browse/ISPN-3086?page=com.atlassian.jira.plugin.... ]
Balazs Zsoldos updated ISPN-3086:
---------------------------------
Description:
I created a very simple application based on https://docs.jboss.org/author/display/ISPN/Using+Infinispan+as+a+JCache+p...
I changed the code to created distributed caches instead of replicated ones. It works until two nodes but if there are three nodes it starts an infinite loop.
*The modified XML contains:*
<namedCache name="namedCache">
<clustering mode="dist" />
</namedCache>
*The modified java code contains:*
CacheManager cacheManager1 = Caching.getCacheManager(new TestClassLoader(tccl), "infinispan-jcache-cluster.xml");
CacheManager cacheManager2 = Caching.getCacheManager(new TestClassLoader(tccl), "infinispan-jcache-cluster.xml");
CacheManager cacheManager3 = Caching.getCacheManager(new TestClassLoader(tccl), "infinispan-jcache-cluster.xml");
*Symptom:*
The code waits on the third command while there is an infinite loop on a background thread. I guess the benefit of distribution would come with more than two nodes but I cannot test it due to the problem above.
Although I used infinispan via JCache I think this issue is not related to the JCache API but it comes from the infinispan core.
*BTW:* Distributed caches seem to me about 30% slower than replicated caches concerning to put and delete functions with two nodes. I guess the benefit would come out between the two topologies with more nodes.
was:
I created a very simple application based on https://docs.jboss.org/author/display/ISPN/Using+Infinispan+as+a+JCache+p...
I changed the code to created distributed caches instead of replicated ones. It works until two nodes but if there are three nodes it starts an infinite loop.
*The modified XML contains:*
<namedCache name="namedCache">
<clustering mode="dist" />
</namedCache>
*The modified java code contains:*
CacheManager cacheManager1 = Caching.getCacheManager(new TestClassLoader(tccl), "infinispan-jcache-cluster.xml");
CacheManager cacheManager2 = Caching.getCacheManager(new TestClassLoader(tccl), "infinispan-jcache-cluster.xml");
CacheManager cacheManager3 = Caching.getCacheManager(new TestClassLoader(tccl), "infinispan-jcache-cluster.xml");
*Symptom:*
The code waits on the third command while there is an infinite loop on a background thread. I guess the benefit of distribution would come with more than two nodes but I cannot test it due to the problem above.
Although I used infinispan via JCache I think this issue is not related to the JCache API but it comes from the infinispan core.
*BTW:* Distributed caches seem to me about 30% slower than replicated caches concerning to put and delete functions with two nodes. I guess the
> Infinite loop when creating more than two Distributed Cache nodes
> -----------------------------------------------------------------
>
> Key: ISPN-3086
> URL: https://issues.jboss.org/browse/ISPN-3086
> Project: Infinispan
> Issue Type: Bug
> Components: JCache
> Affects Versions: 5.3.0.Beta1
> Reporter: Balazs Zsoldos
> Assignee: Galder Zamarreño
> Labels: cache, distribution
> Fix For: 6.0.0.Final
>
>
> I created a very simple application based on https://docs.jboss.org/author/display/ISPN/Using+Infinispan+as+a+JCache+p...
> I changed the code to created distributed caches instead of replicated ones. It works until two nodes but if there are three nodes it starts an infinite loop.
> *The modified XML contains:*
> <namedCache name="namedCache">
> <clustering mode="dist" />
> </namedCache>
> *The modified java code contains:*
> CacheManager cacheManager1 = Caching.getCacheManager(new TestClassLoader(tccl), "infinispan-jcache-cluster.xml");
> CacheManager cacheManager2 = Caching.getCacheManager(new TestClassLoader(tccl), "infinispan-jcache-cluster.xml");
> CacheManager cacheManager3 = Caching.getCacheManager(new TestClassLoader(tccl), "infinispan-jcache-cluster.xml");
> *Symptom:*
> The code waits on the third command while there is an infinite loop on a background thread. I guess the benefit of distribution would come with more than two nodes but I cannot test it due to the problem above.
> Although I used infinispan via JCache I think this issue is not related to the JCache API but it comes from the infinispan core.
> *BTW:* Distributed caches seem to me about 30% slower than replicated caches concerning to put and delete functions with two nodes. I guess the benefit would come out between the two topologies with more nodes.
--
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
11 years, 2 months
[JBoss JIRA] (ISPN-3077) cache.lock should work within the scope of batching
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/ISPN-3077?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero updated ISPN-3077:
----------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> cache.lock should work within the scope of batching
> ---------------------------------------------------
>
> Key: ISPN-3077
> URL: https://issues.jboss.org/browse/ISPN-3077
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.2.6.Final
> Reporter: Mircea Markus
> Assignee: Mircea Markus
> Fix For: 5.3.0.Beta2, 5.3.0.Final
>
>
> {code:java}
> cache.getAdvancedCache().startBatch();
> cache.lock("k");
> ...
> cache.endBatch(..);
> {code}
> The code above throws an exception:
> {quote}
> java.lang.IllegalArgumentException: Cannot create a transactional context without a valid Transaction instance.
> at org.infinispan.context.TransactionalInvocationContextContainer.createInvocationContext(TransactionalInvocationContextContainer.java:113)
> at org.infinispan.context.TransactionalInvocationContextContainer.createInvocationContext(TransactionalInvocationContextContainer.java:108)
> at org.infinispan.CacheImpl.getInvocationContextForWrite(CacheImpl.java:471)
> at org.infinispan.CacheImpl.lock(CacheImpl.java:568)
> at org.infinispan.CacheImpl.lock(CacheImpl.java:553)
> at org.infinispan.api.batch.LockInBatchTest.testLockWithBatching(LockInBatchTest.java:47)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> 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$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:680)
> {quote}
> This logic should be supported, as batching is a convenient way for using transactions without the burden of configuring a transaction manager.
--
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
11 years, 2 months