[JBoss JIRA] (ISPN-5879) XSite client failover - ensure TcpTransportFactory.trySwitchCluster thread safety
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-5879?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-5879:
-----------------------------------------------
Matej Čimbora <mcimbora(a)redhat.com> changed the Status of [bug 1273795|https://bugzilla.redhat.com/show_bug.cgi?id=1273795] from ON_QA to VERIFIED
> XSite client failover - ensure TcpTransportFactory.trySwitchCluster thread safety
> ---------------------------------------------------------------------------------
>
> Key: ISPN-5879
> URL: https://issues.jboss.org/browse/ISPN-5879
> Project: Infinispan
> Issue Type: Bug
> Components: Cross-Site Replication, Remote Protocols
> Reporter: Matej Čimbora
> Assignee: Galder Zamarreño
> Priority: Critical
> Fix For: 8.1.0.CR1
>
>
> When reusing a HotRod client with several threads, site can be accidentally switched multiple times by threads invoking TcpTransportFactory.trySwitchCluster. This occurs when the threads attain 'maxRetries' limit at the same time, each of them being able to invoke TcpTransportFactory..updateServers with different 'clusterAddresses' parameter. This can lead to unpredictable result (e.g. switching back to failed cluster, while the other one (backup) is up and running).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (ISPN-4905) Remove standalone mode from the server distribution
by Alan Field (JIRA)
[ https://issues.jboss.org/browse/ISPN-4905?page=com.atlassian.jira.plugin.... ]
Alan Field closed ISPN-4905.
----------------------------
Resolution: Won't Fix
It's never going away...
> Remove standalone mode from the server distribution
> ---------------------------------------------------
>
> Key: ISPN-4905
> URL: https://issues.jboss.org/browse/ISPN-4905
> Project: Infinispan
> Issue Type: Bug
> Components: Server
> Affects Versions: 7.0.0.CR2
> Reporter: Alan Field
>
> The server currently contains a standalone and clustered mode. The standalone mode can be used for development, but clustered is usually used in production. Removing standalone mode and using a single clustered node for development would mean that the development and production environments are closer to each other and would remove the need to test and verify the standalone mode.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[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:
-----------------------------------------------
Sebastian Łaskawiec <slaskawi(a)redhat.com> changed the Status of [bug 1278991|https://bugzilla.redhat.com/show_bug.cgi?id=1278991] from MODIFIED to ON_QA
> 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