[JBoss JIRA] (ISPN-5927) Infinispan calling setRollbackOnly() when detecting write skew
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-5927?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-5927:
-----------------------------------------------
Vojtech Juranek <vjuranek(a)redhat.com> changed the Status of [bug 1278991|https://bugzilla.redhat.com/show_bug.cgi?id=1278991] from ON_QA to VERIFIED
> Infinispan calling setRollbackOnly() when detecting write skew
> --------------------------------------------------------------
>
> Key: ISPN-5927
> URL: https://issues.jboss.org/browse/ISPN-5927
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 6.0.2.Final
> Reporter: Stephen Fikes
> Assignee: Pedro Ruivo
> Attachments: testcase.zip
>
>
> In the context of Java Data Grid, when Infinispan detects [#write-skew] during prepare, it invokes [#setRollbackOnly]() on the transaction implementation. This results in an exception ({{com.arjuna.ats.jta.exceptions.InvalidTerminationStateException: ARJUNA016064: The transaction is in an invalid state!}}) because this operation is disallowed by Arjuna while in the {{PREPARING}} state. The result is that the causal error ({{org.infinispan.transaction.WriteSkewException}}) is lost and the error that propagates indicates that "invalid state" (of the transaction) is actually the cause of the failed commit. Only when debug logging was enabled could we see the root cause.
> h3. {anchor:write-skew}Write skew exception
> ... org.infinispan.transaction.WriteSkewException: Write skew detected on key <key> for transaction TransactionImple < ... status: ActionStatus.PREPARING >
> at org.infinispan.transaction.WriteSkewHelper.performWriteSkewCheckAndReturnNewVersions(WriteSkewHelper.java:53)
> ...
> at org.infinispan.transaction.TransactionCoordinator.prepare(TransactionCoordinator.java:104)
> at org.infinispan.transaction.xa.TransactionXaAdapter.prepare(TransactionXaAdapter.java:92)
> at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelPrepare(XAResourceRecord.java:213)
> ...
> h3. {anchor:setRollbackOnly}Set Rollback
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.setRollbackOnly(TransactionImple.java:313)
> at org.infinispan.interceptors.InvocationContextInterceptor.markTxForRollbackAndRethrow(InvocationContextInterceptor.java:163)
> ...
> at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:103)
> ...
> at org.infinispan.transaction.xa.TransactionXaAdapter.prepare(TransactionXaAdapter.java:92)
> at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelPrepare(XAResourceRecord.java:213)
> ...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (ISPN-5482) JSR-107 - Provide mechanism to handle expiration events
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-5482?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes updated ISPN-5482:
------------------------------------
Git Pull Request: https://github.com/infinispan/infinispan/pull/3861, https://github.com/infinispan/infinispan/pull/3879 (was: https://github.com/infinispan/infinispan/pull/3879)
> JSR-107 - Provide mechanism to handle expiration events
> --------------------------------------------------------
>
> Key: ISPN-5482
> URL: https://issues.jboss.org/browse/ISPN-5482
> Project: Infinispan
> Issue Type: Feature Request
> Components: JCache
> Reporter: Matej Čimbora
> Assignee: Gustavo Fernandes
> Fix For: 8.1.0.Final, 8.0.3.Final
>
>
> Currently, expiration events are supported only by embedded mode & additionally require entry to be accessed in order to be created. This can lead to CacheEntryExpiredListener not being notified when an entry expires.
> Note: Not covered by TCK tests.
> Example:
> {code}
> @Test
> public void testExpiration(Method m) {
> Cache<String, String> cache1 = getCache1(m);
> Cache<String, String> cache2 = getCache2(m);
> TestExpiredListener listener = new TestExpiredListener();
> MutableCacheEntryListenerConfiguration conf1 = new MutableCacheEntryListenerConfiguration(FactoryBuilder.factoryOf(listener), null, false, false);
> cache1.registerCacheEntryListener(conf1);
> cache2.put("key1", "val1");
> sleep(5000);
> // Required by embedded JCache implementation to work
> assert cache1.get("key1") == null;
> // Failing for remote JCache implementation
> assertEquals(1, listener.invocationCount);
> }
> private static class TestExpiredListener implements CacheEntryExpiredListener, Serializable {
> private int invocationCount;
> @Override
> public void onExpired(Iterable iterable) throws CacheEntryListenerException {
> Iterator iterator = iterable.iterator();
> while (iterator.hasNext()) {
> iterator.next();
> invocationCount++;
> }
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (ISPN-5482) JSR-107 - Provide mechanism to handle expiration events
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-5482?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes updated ISPN-5482:
------------------------------------
Fix Version/s: 8.0.3.Final
> JSR-107 - Provide mechanism to handle expiration events
> --------------------------------------------------------
>
> Key: ISPN-5482
> URL: https://issues.jboss.org/browse/ISPN-5482
> Project: Infinispan
> Issue Type: Feature Request
> Components: JCache
> Reporter: Matej Čimbora
> Assignee: Gustavo Fernandes
> Fix For: 8.1.0.Final, 8.0.3.Final
>
>
> Currently, expiration events are supported only by embedded mode & additionally require entry to be accessed in order to be created. This can lead to CacheEntryExpiredListener not being notified when an entry expires.
> Note: Not covered by TCK tests.
> Example:
> {code}
> @Test
> public void testExpiration(Method m) {
> Cache<String, String> cache1 = getCache1(m);
> Cache<String, String> cache2 = getCache2(m);
> TestExpiredListener listener = new TestExpiredListener();
> MutableCacheEntryListenerConfiguration conf1 = new MutableCacheEntryListenerConfiguration(FactoryBuilder.factoryOf(listener), null, false, false);
> cache1.registerCacheEntryListener(conf1);
> cache2.put("key1", "val1");
> sleep(5000);
> // Required by embedded JCache implementation to work
> assert cache1.get("key1") == null;
> // Failing for remote JCache implementation
> assertEquals(1, listener.invocationCount);
> }
> private static class TestExpiredListener implements CacheEntryExpiredListener, Serializable {
> private int invocationCount;
> @Override
> public void onExpired(Iterable iterable) throws CacheEntryListenerException {
> Iterator iterator = iterable.iterator();
> while (iterator.hasNext()) {
> iterator.next();
> invocationCount++;
> }
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (ISPN-5482) JSR-107 - Provide mechanism to handle expiration events
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-5482?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes reopened ISPN-5482:
-------------------------------------
Reopening until backport applied
> JSR-107 - Provide mechanism to handle expiration events
> --------------------------------------------------------
>
> Key: ISPN-5482
> URL: https://issues.jboss.org/browse/ISPN-5482
> Project: Infinispan
> Issue Type: Feature Request
> Components: JCache
> Reporter: Matej Čimbora
> Assignee: Gustavo Fernandes
> Fix For: 8.1.0.Final
>
>
> Currently, expiration events are supported only by embedded mode & additionally require entry to be accessed in order to be created. This can lead to CacheEntryExpiredListener not being notified when an entry expires.
> Note: Not covered by TCK tests.
> Example:
> {code}
> @Test
> public void testExpiration(Method m) {
> Cache<String, String> cache1 = getCache1(m);
> Cache<String, String> cache2 = getCache2(m);
> TestExpiredListener listener = new TestExpiredListener();
> MutableCacheEntryListenerConfiguration conf1 = new MutableCacheEntryListenerConfiguration(FactoryBuilder.factoryOf(listener), null, false, false);
> cache1.registerCacheEntryListener(conf1);
> cache2.put("key1", "val1");
> sleep(5000);
> // Required by embedded JCache implementation to work
> assert cache1.get("key1") == null;
> // Failing for remote JCache implementation
> assertEquals(1, listener.invocationCount);
> }
> private static class TestExpiredListener implements CacheEntryExpiredListener, Serializable {
> private int invocationCount;
> @Override
> public void onExpired(Iterable iterable) throws CacheEntryListenerException {
> Iterator iterator = iterable.iterator();
> while (iterator.hasNext()) {
> iterator.next();
> invocationCount++;
> }
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (ISPN-5482) JSR-107 - Provide mechanism to handle expiration events
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-5482?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes updated ISPN-5482:
------------------------------------
Status: Pull Request Sent (was: Reopened)
Git Pull Request: https://github.com/infinispan/infinispan/pull/3879 (was: https://github.com/infinispan/infinispan/pull/3861)
> JSR-107 - Provide mechanism to handle expiration events
> --------------------------------------------------------
>
> Key: ISPN-5482
> URL: https://issues.jboss.org/browse/ISPN-5482
> Project: Infinispan
> Issue Type: Feature Request
> Components: JCache
> Reporter: Matej Čimbora
> Assignee: Gustavo Fernandes
> Fix For: 8.1.0.Final
>
>
> Currently, expiration events are supported only by embedded mode & additionally require entry to be accessed in order to be created. This can lead to CacheEntryExpiredListener not being notified when an entry expires.
> Note: Not covered by TCK tests.
> Example:
> {code}
> @Test
> public void testExpiration(Method m) {
> Cache<String, String> cache1 = getCache1(m);
> Cache<String, String> cache2 = getCache2(m);
> TestExpiredListener listener = new TestExpiredListener();
> MutableCacheEntryListenerConfiguration conf1 = new MutableCacheEntryListenerConfiguration(FactoryBuilder.factoryOf(listener), null, false, false);
> cache1.registerCacheEntryListener(conf1);
> cache2.put("key1", "val1");
> sleep(5000);
> // Required by embedded JCache implementation to work
> assert cache1.get("key1") == null;
> // Failing for remote JCache implementation
> assertEquals(1, listener.invocationCount);
> }
> private static class TestExpiredListener implements CacheEntryExpiredListener, Serializable {
> private int invocationCount;
> @Override
> public void onExpired(Iterable iterable) throws CacheEntryListenerException {
> Iterator iterator = iterable.iterator();
> while (iterator.hasNext()) {
> iterator.next();
> invocationCount++;
> }
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (ISPN-5948) ClusterListenerDistTxTest.testSimpleExpirationFilterNotOwner and ClusterListenerDistTxTest.testSimpleExpirationConverterNotOwner fail with assertion error
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-5948?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-5948:
-------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> ClusterListenerDistTxTest.testSimpleExpirationFilterNotOwner and ClusterListenerDistTxTest.testSimpleExpirationConverterNotOwner fail with assertion error
> ----------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-5948
> URL: https://issues.jboss.org/browse/ISPN-5948
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Core
> Reporter: Roman Macor
> Assignee: William Burns
> Labels: testsuite_stability
> Fix For: 8.1.0.Final
>
> Attachments: ClusterListenerDistTxTest.log.gz
>
>
> ClusterListenerDistTxTest.testSimpleExpirationFilterNotOwner fails with:
> Error Message
> expected:<MagicKey#null{2ea2ae14@ClusterListenerDistTxTest-NodeDE-7642/40}-expiring> but was:<null>
> Stacktrace
> java.lang.AssertionError: expected:<MagicKey#null{2ea2ae14@ClusterListenerDistTxTest-NodeDE-7642/40}-expiring> but was:<null>
> at org.testng.AssertJUnit.fail(AssertJUnit.java:59)
> at org.testng.AssertJUnit.failNotEquals(AssertJUnit.java:364)
> at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:80)
> at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:88)
> at org.infinispan.notifications.cachelistener.cluster.AbstractClusterListenerUtilTest.verifySimpleExpirationEvents(AbstractClusterListenerUtilTest.java:292)
> at org.infinispan.notifications.cachelistener.cluster.AbstractClusterListenerTest.testExpirationFilter(AbstractClusterListenerTest.java:735)
> at org.infinispan.notifications.cachelistener.cluster.AbstractClusterListenerTest.testSimpleExpirationFilter(AbstractClusterListenerTest.java:705)
> at org.infinispan.notifications.cachelistener.cluster.AbstractClusterListenerTest.testSimpleExpirationFilterNotOwner(AbstractClusterListenerTest.java:692)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:56)
> at java.lang.reflect.Method.invoke(Method.java:620)
> 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:274)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1157)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:627)
> at java.lang.Thread.run(Thread.java:809)
> ClusterListenerDistTxTest.testSimpleExpirationConverterNotOwner fails with:
> Error Message
> expected:<fi> but was:<null>
> Stacktrace
> java.lang.AssertionError: expected:<fi> but was:<null>
> at org.testng.AssertJUnit.fail(AssertJUnit.java:59)
> at org.testng.AssertJUnit.failNotEquals(AssertJUnit.java:364)
> at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:80)
> at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:88)
> at org.infinispan.notifications.cachelistener.cluster.AbstractClusterListenerUtilTest.verifySimpleExpirationEvents(AbstractClusterListenerUtilTest.java:292)
> at org.infinispan.notifications.cachelistener.cluster.AbstractClusterListenerTest.testExpirationConverter(AbstractClusterListenerTest.java:767)
> at org.infinispan.notifications.cachelistener.cluster.AbstractClusterListenerTest.testSimpleExpirationConverterNotOwner(AbstractClusterListenerTest.java:742)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:56)
> at java.lang.reflect.Method.invoke(Method.java:620)
> 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:274)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1157)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:627)
> at java.lang.Thread.run(Thread.java:809)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (ISPN-5883) Node can apply new topology after sending status response
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-5883?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-5883:
-------------------------------
Git Pull Request: https://github.com/infinispan/infinispan/pull/3782, https://github.com/infinispan/infinispan/pull/3877 (was: https://github.com/infinispan/infinispan/pull/3782)
> Node can apply new topology after sending status response
> ---------------------------------------------------------
>
> Key: ISPN-5883
> URL: https://issues.jboss.org/browse/ISPN-5883
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Test Suite - Core
> Affects Versions: 8.0.1.Final, 7.2.5.Final, 8.1.0.Alpha2
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Critical
> Labels: testsuite_stability
> Fix For: 8.1.0.Final
>
>
> {{LocalTopologyManagerImpl}} is responsible for sending the {{ClusterTopologyControlCommand(GET_STATUS)}} response, and when it sends the response it doesn't check the current view id against the new coordinator's view id. If the old coordinator already sent a topology update before the merge, that topology update might be processed after sending the status response. The new coordinator will send a topology update with a topology id of {{max(status response topology ids) + 1}}. The node will then process the topology update from the old coordinator, but it will ignore the topology update from the new coordinator with the same topology id.
> This is extra common in the partition handling tests, e.g. {{BasePessimisticTxPartitionAndMergeTest}} subclasses, because the test "injects" the JGroups view on each node serially, and often the 4th node sends the status response before it gets the new view.
> {noformat}
> 22:16:37,776 DEBUG (remote-thread-NodeD-p26-t6:[]) [LocalTopologyManagerImpl] Sending cluster status response for view 10
> // Topology from NodeC
> 22:16:37,778 DEBUG (transport-thread-NodeD-p28-t2:[]) [LocalTopologyManagerImpl] Updating local topology for cache pes-cache: CacheTopology{id=8, rebalanceId=3, currentCH=DefaultConsistentHash{ns=60, owners = (4)[NodeA-37631: 15+15, NodeB-47846: 15+15, NodeC-46467: 15+15, NodeD-30486: 15+15]}, pendingCH=null, unionCH=null, actualMembers=[NodeC-46467, NodeD-30486]}
> // Later, topology from NodeA
> 22:16:37,827 DEBUG (transport-thread-NodeD-p28-t1:[]) [LocalTopologyManagerImpl] Ignoring late consistent hash update for cache pes-cache, current topology is 8: CacheTopology{id=8, rebalanceId=3, currentCH=DefaultConsistentHash{ns=60, owners = (4)[NodeA-37631: 15+15, NodeB-47846: 15+15, NodeC-46467: 15+15, NodeD-30486: 15+15]}, pendingCH=null, unionCH=null, actualMembers=[NodeA-37631, NodeB-47846, NodeC-46467, NodeD-30486]}
> {noformat}
> As a solution, we can delay sending the status response until we have the same view as the coordinator (or a later one). We already check that the sender is the current coordinator before applying a topology update, so this will guarantee that the we don't apply other topology updates from the old coordinator. Since the status request is only sent after the new view was installed, this will not introduce any delays in the vast majority of cases.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months