[JBoss JIRA] (ISPN-4167) DummyBaseTransactionManager doesn't clean up when rollback fails
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-4167?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-4167:
------------------------------
Fix Version/s: 7.1.0.Beta1
(was: 7.1.0.Alpha1)
> DummyBaseTransactionManager doesn't clean up when rollback fails
> ----------------------------------------------------------------
>
> Key: ISPN-4167
> URL: https://issues.jboss.org/browse/ISPN-4167
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 6.0.2.Final
> Reporter: Dan Berindei
> Fix For: 7.1.0.Beta1
>
>
> If the rollback fails, the thread local holding the current transaction is not cleared, and it becomes impossible to start a new transaction on the same thread.
> One way this can happen is when Infinispan registers as a XA transaction, but DummyTransactionManager is not configured to use XA Xids:
> {noformat}
> 12:47:57,169 ERROR (testng-ReplicationExceptionTest:) [DummyTransaction] ISPN000098: Exception while rollback
> java.lang.UnsupportedOperationException
> at org.infinispan.transaction.tm.DummyNoXaXid.getBranchQualifier(DummyNoXaXid.java:30)
> at org.infinispan.transaction.xa.recovery.SerializableXid.<init>(SerializableXid.java:37)
> at org.infinispan.transaction.xa.TransactionXaAdapter.convertXid(TransactionXaAdapter.java:251)
> at org.infinispan.transaction.xa.TransactionXaAdapter.rollback(TransactionXaAdapter.java:122)
> at org.infinispan.transaction.tm.DummyTransaction.runRollback(DummyTransaction.java:281)
> at org.infinispan.transaction.tm.DummyTransaction.rollback(DummyTransaction.java:88)
> at org.infinispan.transaction.tm.DummyBaseTransactionManager.rollback(DummyBaseTransactionManager.java:104)
> at org.infinispan.CacheImpl.tryRollback(CacheImpl.java:1442)
> at org.infinispan.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1418)
> at org.infinispan.CacheImpl.putInternal(CacheImpl.java:894)
> at org.infinispan.CacheImpl.put(CacheImpl.java:886)
> at org.infinispan.CacheImpl.put(CacheImpl.java:1461)
> at org.infinispan.CacheImpl.put(CacheImpl.java:225)
> at org.infinispan.tx.synchronisation.ReplicationExceptionTest.testSyncReplTimeout(ReplicationExceptionTest.java:54)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 5 months
[JBoss JIRA] (ISPN-4159) DefaultTwoWayKey2StringMapper encodes objects to strings in a manner that is incompatible with string handling of some databases
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-4159?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-4159:
------------------------------
Fix Version/s: 7.1.0.Beta1
(was: 7.1.0.Alpha1)
> DefaultTwoWayKey2StringMapper encodes objects to strings in a manner that is incompatible with string handling of some databases
> --------------------------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-4159
> URL: https://issues.jboss.org/browse/ISPN-4159
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 6.0.0.Final
> Reporter: Adrian Nistor
> Assignee: Adrian Nistor
> Fix For: 7.1.0.Beta1
>
>
> DefaultTwoWayKey2StringMapper uses two neat tricks.
> 1. it does not encode all supported types, it only encodes non-Strings. Strings are kept unmodified.
> 2. it uses a special prefix (unicode char 0xfeff) to mark which strings were encoded and which are plain.
> Unfortunately some databases, notably MySql, interpret the endianness mark (0xfeff, 0xfffe), convert to native byte order and then drop it.
> This leaves us with no clue the string is not an actual String but an encoded representation of another type. This misinterpretation leads later to ClassCastExceptions in various places in core and user code.
> Proposed fix: get rid of #1 and #2 optimisations. Encode all objects, including Strings and always use the ?n prefix (where n stands for the original type). Drop the 0xFEFF marker prefix.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 5 months
[JBoss JIRA] (ISPN-4262) Rolling back a transaction after commit timeout should release locks in two phases
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-4262?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-4262:
------------------------------
Fix Version/s: 7.1.0.Beta1
(was: 7.1.0.Alpha1)
> Rolling back a transaction after commit timeout should release locks in two phases
> ----------------------------------------------------------------------------------
>
> Key: ISPN-4262
> URL: https://issues.jboss.org/browse/ISPN-4262
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Transactions
> Affects Versions: 6.0.2.Final
> Reporter: Dan Berindei
> Fix For: 7.1.0.Beta1
>
>
> This is related to ISPN-4137.
> When a commit command times out, we send a rollback command to release locks. The problem is that the node that timed out might still execute commit command, before the rollback command reaching the backup but after it released the locks on the primary owner.
> The solution is to not release any locks during the rollback command's execution, but send an asynchronous TxCompletionNotification afterwards - just like for commit commands.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 5 months
[JBoss JIRA] (ISPN-4190) Use Message.Flag.DONT_LOOPBACK instead of RequestOptions.setExclusionList
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-4190?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-4190:
------------------------------
Fix Version/s: 7.1.0.Beta1
(was: 7.1.0.Alpha1)
> Use Message.Flag.DONT_LOOPBACK instead of RequestOptions.setExclusionList
> -------------------------------------------------------------------------
>
> Key: ISPN-4190
> URL: https://issues.jboss.org/browse/ISPN-4190
> Project: Infinispan
> Issue Type: Task
> Components: Core
> Affects Versions: 7.0.0.Alpha2
> Reporter: Dan Berindei
> Fix For: 7.1.0.Beta1
>
>
> We are currently using {{RequestOptions.setExclusionList(channel.getAddress())}} in CommandAwareRpcDispatcher, to prevent the sender of an RPC to receive that message. We can't use {{Channel.setDiscardOwnMessages(true)}}, because TO requires messages to be delivered to self.
> JGroups 3.5.0.Beta2 has added a {{DONT_LOOPBACK}} flag, which should be a lot more efficient than using the exclusion list. We should start using it.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 5 months
[JBoss JIRA] (ISPN-4404) The coordinator leaving the cluster should not cancel state transfer
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-4404?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-4404:
------------------------------
Fix Version/s: 7.1.0.Beta1
(was: 7.1.0.Alpha1)
> The coordinator leaving the cluster should not cancel state transfer
> --------------------------------------------------------------------
>
> Key: ISPN-4404
> URL: https://issues.jboss.org/browse/ISPN-4404
> Project: Infinispan
> Issue Type: Enhancement
> Components: Core, State Transfer
> Affects Versions: 6.0.2.Final
> Reporter: Dan Berindei
> Fix For: 7.1.0.Beta1
>
>
> When the cluster coordinator changes or a merge view is received, the new coordinator tries to reconcile the cache topologies of the different partitions and cancels any state transfer in progress.
> But most of the time, the coordinator changing doesn't mean that there are multiple partitions, just that the old coordinator died. In that case there is a single cache topology, so there is nothing to reconcile and no reason to cancel the pending ST.
> We can't rely on the new coordinator receiving a MergeView, because the old coordinator might have received a MergeView and died soon afterwards.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 5 months
[JBoss JIRA] (ISPN-4351) Clarify the behaviour of putForExternalRead in clustered caches
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-4351?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-4351:
------------------------------
Fix Version/s: 7.1.0.Beta1
(was: 7.1.0.Alpha1)
> Clarify the behaviour of putForExternalRead in clustered caches
> ---------------------------------------------------------------
>
> Key: ISPN-4351
> URL: https://issues.jboss.org/browse/ISPN-4351
> Project: Infinispan
> Issue Type: Task
> Components: Core, Documentation-Core
> Affects Versions: 6.0.2.Final
> Reporter: Dan Berindei
> Fix For: 7.1.0.Beta1
>
>
> The {{putForExternal}} [documentation|http://infinispan.org/docs/7.0.x/user_guide/user_guide.html...] says
> {quote}
> putForExternalRead is consider to be a fast operation because regardless of whether it’s successful or not, it doesn’t wait for any locks, and so returns to the caller promptly.
> {quote}
> But the documentation doesn't say how {{putForExternalRead}} should behave in a clustered cache. Currently, the command is replicated to all the owners in distributed mode, and to all the cluster members in replicated mode. So the command may be delayed while waiting for the responses from those other nodes. The exception is invalidation mode, which doesn't replicate {{putForExternalRead}} commands - only regular {{put}}s generate invalidations.
> The documentation also doesn't mention the interaction of {{putForExternalRead}} operations with transactions. Currently, {{PUT_FOR_EXTERNAL_READ}}-flagged commands are executed as non-transactional commands even when the cache is transactional, presumably to avoid the overhead of transactions. But this undermines the argument for wrapping regular write operations in an implicit transaction, when running in a transactional cache.
> I propose changing {{putForExternalRead}} to only write on the local node (as it already does in invalidation mode), and documenting it as such. In distribution mode, it should be a no-op when the local node is not an owner.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 5 months
[JBoss JIRA] (ISPN-4286) Two concurrent putIfAbsent operations can both return null during rebalance
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-4286?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-4286:
------------------------------
Fix Version/s: 7.1.0.Beta1
(was: 7.1.0.Alpha1)
> Two concurrent putIfAbsent operations can both return null during rebalance
> ---------------------------------------------------------------------------
>
> Key: ISPN-4286
> URL: https://issues.jboss.org/browse/ISPN-4286
> Project: Infinispan
> Issue Type: Bug
> Components: Core, State Transfer
> Affects Versions: 6.0.2.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Critical
> Fix For: 7.1.0.Beta1
>
>
> If the cache topology changes while executing a putIfAbsent operation, the old primary owner will throw an OutdatedTopologyException, and the originator will retry on the new owner.
> When retrying the PutKeyValueCommand on the new primary owner, we compare the current value with the command's new value. If they are equal, we assume that the initial command wrote the old value, and we return {{null}}.
> However, the value might have been written by another putIfAbsent operation. So we could have two {{putIfAbsent(k, v)}} operations, both returning {{null}}.
> {code}
> A is the originator, B is the primary owner, k = null
> A -> B: putIfAbsent(k, v1)
> B dies before writing v, C is now primary owner
> D -> C: putIfAbsent(k, v1) // another put operation from D, with the same value
> C -> D: null // correct
> A -> C: retry_putIfAbsent(k, v1)
> C -> A: null // C assumes A is overwriting its own value, so it's also returning null
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 5 months