[JBoss JIRA] (ISPN-11167) Retrying transactions after WriteSkewException should be easier
by Dan Berindei (Jira)
Dan Berindei created ISPN-11167:
-----------------------------------
Summary: Retrying transactions after WriteSkewException should be easier
Key: ISPN-11167
URL: https://issues.redhat.com/browse/ISPN-11167
Project: Infinispan
Issue Type: Bug
Components: Core, Documentation
Affects Versions: 10.1.0.Final
Reporter: Dan Berindei
Fix For: 11.0.0.Final
I've added the documentation tag because we "know" users of optimistic transactions
should catch {{WriteSkewException}}s and retry, but the user guide never explains how a user should do it.
It turns out the exception tree is really complicated:
{noformat}
javax.transaction.RollbackException: ARJUNA016053: Could not commit transaction.
at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1299) Suppressed: javax.transaction.xa.XAException
at org.infinispan.transaction.impl.TransactionCoordinator.prepare(TransactionCoordinator.java:143)
Caused by: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from ...
at org.infinispan.remoting.transport.ResponseCollectors.wrapRemoteException(ResponseCollectors.java:25)
Suppressed: org.infinispan.util.logging.TraceException
at org.infinispan.interceptors.impl.SimpleAsyncInvocationStage.get(SimpleAsyncInvocationStage.java:39)
Caused by: org.infinispan.transaction.WriteSkewException: Write skew detected on key ...
at org.infinispan.marshall.exts.ThrowableExternalizer.readObject(ThrowableExternalizer.java:257)
{noformat}
Part of the problem is internal: we shouldn't wrap {{WriteSkewException}} in a {{RemoteException}}.
The other part is harder to control: Narayana makes our {{XAException}} a suppressed exception instead of a cause,
probably because in the general case multiple XA resources could fail to prepare.
Initially I thought the XAException was suppressed because Narayana committed the transaction in one phase,
but I disabled {{CoordinatorEnvironmentBean.commitOnePhase}} and it's still suppressed.
OTOH the exception tree could be much simpler with {{useSynchronization(true)}},
if it weren't for our own gratuitous wrapping:
{noformat}
javax.transaction.RollbackException: ARJUNA016053: Could not commit transaction.
at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1299)
Caused by: org.infinispan.commons.CacheException: Could not prepare.
at org.infinispan.transaction.impl.TransactionTable.beforeCompletion(TransactionTable.java:898)
Caused by: javax.transaction.xa.XAException
at org.infinispan.transaction.impl.TransactionCoordinator.prepare(TransactionCoordinator.java:143)
Caused by: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from ...
at org.infinispan.remoting.transport.ResponseCollectors.wrapRemoteException(ResponseCollectors.java:25)
Suppressed: org.infinispan.util.logging.TraceException
at org.infinispan.interceptors.impl.SimpleAsyncInvocationStage.get(SimpleAsyncInvocationStage.java:39)
Caused by: org.infinispan.transaction.WriteSkewException: Write skew detected on key ...
at org.infinispan.marshall.exts.ThrowableExternalizer.readObject(ThrowableExternalizer.java:257)
{noformat}
We could remove the {{CacheException}}, the {{XAException}}, and the {{RemoteException}},
leaving just a {{RollbackException}} caused by a {{WriteSkewException}}.
For implicit transactions we add yet another wrapper:
sync operations wrap the {{RollbackException}} in a {{CacheException}},
async operations wrap it in a {{CompletionException}}.
We could instead check if the exception is caused by a {{WriteSkewException}} and unwrap it.
We should definitely add a helper static method for the users to check if they should retry the transaction,
something like {{CacheTransactions.isWriteSkew(RollbackException)}},
and we should change the write skew to use it.
Currently they are content to catch a {{RollbackException}} and assume it has a {{WriteSkewException}} inside.
We should also add a {{useSynchronization}} parameter to {{AbstractClusteredWriteSkewTest}} and all the write skew tests.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 11 months
[JBoss JIRA] (ISPN-11166) SocketTimeoutFailureRetryTest random failures
by Dan Berindei (Jira)
Dan Berindei created ISPN-11166:
-----------------------------------
Summary: SocketTimeoutFailureRetryTest random failures
Key: ISPN-11166
URL: https://issues.redhat.com/browse/ISPN-11166
Project: Infinispan
Issue Type: Bug
Components: Server, Test Suite
Affects Versions: 10.1.0.Final
Reporter: Dan Berindei
Assignee: Dan Berindei
Fix For: 10.1.1.Final
Replicated non-tx caches without stores have an optimization for get operations to bypass the interceptor chain and query the data container directly. The optimization was added with the non-blocking listener changes, in order to compensate their overhead, but it only covered {{get()}} and {{getAsync()}}, while the HotRod server uses {{getCacheEntryAsync()}}.
The ISPN-11020 fix extended the replicated get optimization to {{getCacheEntryAsync()}}, so now HotRod replicated reads bypass the interceptor chain, including the {{DelayingInterceptor}} added by {{SocketTimeoutFailureRetryTest}}.
{noformat}
java.lang.AssertionError: expected:<1> but was:<0>
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:170)
at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:177)
at org.infinispan.client.hotrod.retry.SocketTimeoutFailureRetryTest.testRetrySocketTimeout(SocketTimeoutFailureRetryTest.java:68)
{noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 11 months
[JBoss JIRA] (ISPN-11166) SocketTimeoutFailureRetryTest random failures
by Dan Berindei (Jira)
[ https://issues.redhat.com/browse/ISPN-11166?page=com.atlassian.jira.plugi... ]
Dan Berindei updated ISPN-11166:
--------------------------------
Status: Open (was: New)
> SocketTimeoutFailureRetryTest random failures
> ---------------------------------------------
>
> Key: ISPN-11166
> URL: https://issues.redhat.com/browse/ISPN-11166
> Project: Infinispan
> Issue Type: Bug
> Components: Server, Test Suite
> Affects Versions: 10.1.0.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Labels: testsuite_stability
> Fix For: 10.1.1.Final
>
>
> Replicated non-tx caches without stores have an optimization for get operations to bypass the interceptor chain and query the data container directly. The optimization was added with the non-blocking listener changes, in order to compensate their overhead, but it only covered {{get()}} and {{getAsync()}}, while the HotRod server uses {{getCacheEntryAsync()}}.
> The ISPN-11020 fix extended the replicated get optimization to {{getCacheEntryAsync()}}, so now HotRod replicated reads bypass the interceptor chain, including the {{DelayingInterceptor}} added by {{SocketTimeoutFailureRetryTest}}.
> {noformat}
> java.lang.AssertionError: expected:<1> but was:<0>
> 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:170)
> at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:177)
> at org.infinispan.client.hotrod.retry.SocketTimeoutFailureRetryTest.testRetrySocketTimeout(SocketTimeoutFailureRetryTest.java:68)
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 11 months
[JBoss JIRA] (ISPN-11165) Remove JBossTS dependency
by Dan Berindei (Jira)
Dan Berindei created ISPN-11165:
-----------------------------------
Summary: Remove JBossTS dependency
Key: ISPN-11165
URL: https://issues.redhat.com/browse/ISPN-11165
Project: Infinispan
Issue Type: Task
Components: Dependency
Affects Versions: 10.1.0.Final
Reporter: Dan Berindei
Fix For: 10.1.1.Final
We already have Narayana, which is JBossTS 5, so there's no need to keep JBossTS 4.x around.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 11 months
[JBoss JIRA] (ISPN-11135) Remove the GUI demo module
by Tristan Tarrant (Jira)
[ https://issues.redhat.com/browse/ISPN-11135?page=com.atlassian.jira.plugi... ]
Tristan Tarrant updated ISPN-11135:
-----------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 10.1.1.Final
(was: 11.0.0.Final)
Resolution: Done
> Remove the GUI demo module
> --------------------------
>
> Key: ISPN-11135
> URL: https://issues.redhat.com/browse/ISPN-11135
> Project: Infinispan
> Issue Type: Task
> Affects Versions: 10.1.0.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 10.1.1.Final
>
>
> The GUI demo module hasn't been maintained lately, and in fact the launch scripts don't work because they are still using the uber jars.
> We should remove it and instead the server CLI + console should serve as a demo.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 11 months