[jira] [Updated] (IGNITE-6527) Deadlock detection works incorrectly with deadlocks that are not the cause of the timeout.
[ https://issues.apache.org/jira/browse/IGNITE-6527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vitaliy Biryukov updated IGNITE-6527: - Description: *requested keys:* keys primary for the same node and blocking in sequential order during the timeout (or all keys that haven't locked by an optimistic transaction in case of near cache). *candidates:* keys candidates to be locked on a primary node (entries contains in GridDhtTxLocal). In the process of updating the Wait-For-Graph requested keys used as candidates. But "TxDeadlock.toString" method use candidates which were received from messages. 1) It causes an incorrect error message. Example: K1: TX1 holds lock, TX2 waits lock. K2: TX3 holds lock, TX1 waits lock. Transactions: TX1 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, nodeOrder=1], nodeId=f03b1ae3-a100-479c-9671-11d5cef0, threadId=455] TX2 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, nodeOrder=2], nodeId=2c0c0e78-cab2-4b23-a985-4965e421, threadId=456] TX3 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, nodeOrder=3], nodeId=3340dc48-f1a1-4ea8-8742-19b31432, threadId=457] Keys: K1 [key=6, cache=cache] K2 [key=1, cache=cache] was: *requested keys:* keys primary for the same node and blocking in sequential order during the timeout (or all keys that haven't locked by an optimistic transaction in case of near cache). *candidates:* keys candidates to be locked on a primary node (entries contains in GridDhtTxLocal). In the process of updating the Wait-For-Graph requested keys used as candidates. But "TxDeadlock.toString" method use candidates which were received from messages. It causes an incorrect error message. Example: K1: TX1 holds lock, TX2 waits lock. K2: TX3 holds lock, TX1 waits lock. Transactions: TX1 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, nodeOrder=1], nodeId=f03b1ae3-a100-479c-9671-11d5cef0, threadId=455] TX2 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, nodeOrder=2], nodeId=2c0c0e78-cab2-4b23-a985-4965e421, threadId=456] TX3 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, nodeOrder=3], nodeId=3340dc48-f1a1-4ea8-8742-19b31432, threadId=457] Keys: K1 [key=6, cache=cache] K2 [key=1, cache=cache] > Deadlock detection works incorrectly with deadlocks that are not the cause of > the timeout. > -- > > Key: IGNITE-6527 > URL: https://issues.apache.org/jira/browse/IGNITE-6527 > Project: Ignite > Issue Type: Bug >Reporter: Vitaliy Biryukov >Assignee: Vitaliy Biryukov > > *requested keys:* keys primary for the same node and blocking in sequential > order during the timeout (or all keys that haven't locked by an optimistic > transaction in case of near cache). > *candidates:* keys candidates to be locked on a primary node (entries > contains in GridDhtTxLocal). > In the process of updating the Wait-For-Graph requested keys used as > candidates. But "TxDeadlock.toString" method use candidates which were > received from messages. > 1) It causes an incorrect error message. > Example: > K1: TX1 holds lock, TX2 waits lock. > K2: TX3 holds lock, TX1 waits lock. > Transactions: > TX1 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, > nodeOrder=1], nodeId=f03b1ae3-a100-479c-9671-11d5cef0, threadId=455] > TX2 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, > nodeOrder=2], nodeId=2c0c0e78-cab2-4b23-a985-4965e421, threadId=456] > TX3 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, > nodeOrder=3], nodeId=3340dc48-f1a1-4ea8-8742-19b31432, threadId=457] > Keys: > K1 [key=6, cache=cache] > K2 [key=1, cache=cache] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6527) Deadlock detection works incorrectly with deadlocks that are not the cause of the timeout.
[ https://issues.apache.org/jira/browse/IGNITE-6527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vitaliy Biryukov updated IGNITE-6527: - Description: *requested keys:* keys primary for the same node and blocking in sequential order during the timeout (or all keys that haven't locked by an optimistic transaction in case of near cache). *candidates:* keys candidates to be locked on a primary node (entries contains in GridDhtTxLocal). In the process of updating the Wait-For-Graph requested keys used as candidates. But "TxDeadlock.toString" method use candidates which were received from messages. It causes an incorrect error message. Example: K1: TX1 holds lock, TX2 waits lock. K2: TX3 holds lock, TX1 waits lock. Transactions: TX1 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, nodeOrder=1], nodeId=f03b1ae3-a100-479c-9671-11d5cef0, threadId=455] TX2 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, nodeOrder=2], nodeId=2c0c0e78-cab2-4b23-a985-4965e421, threadId=456] TX3 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, nodeOrder=3], nodeId=3340dc48-f1a1-4ea8-8742-19b31432, threadId=457] Keys: K1 [key=6, cache=cache] K2 [key=1, cache=cache] was: *requested keys:* keys primary for the same node and blocking in sequential order during the timeout (or all keys that haven't locked by an optimistic transaction in case of near cache). *candidates: * keys candidates to be locked on a primary node (entries contains in GridDhtTxLocal). In the process of updating the Wait-For-Graph requested keys used as candidates. But "TxDeadlock.toString" method use candidates which were received from messages. It causes an incorrect error message. Example: K1: TX1 holds lock, TX2 waits lock. K2: TX3 holds lock, TX1 waits lock. Transactions: TX1 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, nodeOrder=1], nodeId=f03b1ae3-a100-479c-9671-11d5cef0, threadId=455] TX2 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, nodeOrder=2], nodeId=2c0c0e78-cab2-4b23-a985-4965e421, threadId=456] TX3 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, nodeOrder=3], nodeId=3340dc48-f1a1-4ea8-8742-19b31432, threadId=457] Keys: K1 [key=6, cache=cache] K2 [key=1, cache=cache] > Deadlock detection works incorrectly with deadlocks that are not the cause of > the timeout. > -- > > Key: IGNITE-6527 > URL: https://issues.apache.org/jira/browse/IGNITE-6527 > Project: Ignite > Issue Type: Bug >Reporter: Vitaliy Biryukov >Assignee: Vitaliy Biryukov > > *requested keys:* keys primary for the same node and blocking in sequential > order during the timeout (or all keys that haven't locked by an optimistic > transaction in case of near cache). > *candidates:* keys candidates to be locked on a primary node (entries > contains in GridDhtTxLocal). > In the process of updating the Wait-For-Graph requested keys used as > candidates. But "TxDeadlock.toString" method use candidates which were > received from messages. It causes an incorrect error message. > Example: > K1: TX1 holds lock, TX2 waits lock. > K2: TX3 holds lock, TX1 waits lock. > Transactions: > TX1 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, > nodeOrder=1], nodeId=f03b1ae3-a100-479c-9671-11d5cef0, threadId=455] > TX2 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, > nodeOrder=2], nodeId=2c0c0e78-cab2-4b23-a985-4965e421, threadId=456] > TX3 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, > nodeOrder=3], nodeId=3340dc48-f1a1-4ea8-8742-19b31432, threadId=457] > Keys: > K1 [key=6, cache=cache] > K2 [key=1, cache=cache] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6527) Deadlock detection works incorrectly with deadlocks that are not the cause of the timeout.
[ https://issues.apache.org/jira/browse/IGNITE-6527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vitaliy Biryukov updated IGNITE-6527: - Description: *requested keys:* keys primary for the same node and blocking in sequential order during the timeout (or all keys that haven't locked by an optimistic transaction in case of near cache). *candidates: * keys candidates to be locked on a primary node (entries contains in GridDhtTxLocal). In the process of updating the Wait-For-Graph requested keys used as candidates. But "TxDeadlock.toString" method use candidates which were received from messages. It causes an incorrect error message. Example: K1: TX1 holds lock, TX2 waits lock. K2: TX3 holds lock, TX1 waits lock. Transactions: TX1 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, nodeOrder=1], nodeId=f03b1ae3-a100-479c-9671-11d5cef0, threadId=455] TX2 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, nodeOrder=2], nodeId=2c0c0e78-cab2-4b23-a985-4965e421, threadId=456] TX3 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, nodeOrder=3], nodeId=3340dc48-f1a1-4ea8-8742-19b31432, threadId=457] Keys: K1 [key=6, cache=cache] K2 [key=1, cache=cache] > Deadlock detection works incorrectly with deadlocks that are not the cause of > the timeout. > -- > > Key: IGNITE-6527 > URL: https://issues.apache.org/jira/browse/IGNITE-6527 > Project: Ignite > Issue Type: Bug >Reporter: Vitaliy Biryukov >Assignee: Vitaliy Biryukov > > *requested keys:* keys primary for the same node and blocking in sequential > order during the timeout (or all keys that haven't locked by an optimistic > transaction in case of near cache). > *candidates: * keys candidates to be locked on a primary node (entries > contains in GridDhtTxLocal). > In the process of updating the Wait-For-Graph requested keys used as > candidates. But "TxDeadlock.toString" method use candidates which were > received from messages. It causes an incorrect error message. > Example: > K1: TX1 holds lock, TX2 waits lock. > K2: TX3 holds lock, TX1 waits lock. > Transactions: > TX1 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, > nodeOrder=1], nodeId=f03b1ae3-a100-479c-9671-11d5cef0, threadId=455] > TX2 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, > nodeOrder=2], nodeId=2c0c0e78-cab2-4b23-a985-4965e421, threadId=456] > TX3 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, > nodeOrder=3], nodeId=3340dc48-f1a1-4ea8-8742-19b31432, threadId=457] > Keys: > K1 [key=6, cache=cache] > K2 [key=1, cache=cache] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6527) Deadlock detection works incorrectly with deadlocks that are not the cause of the timeout.
[ https://issues.apache.org/jira/browse/IGNITE-6527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vitaliy Biryukov updated IGNITE-6527: - Summary: Deadlock detection works incorrectly with deadlocks that are not the cause of the timeout. (was: Deadlock detection works incorrect with deadlocks that are not the cause of the timeout.) > Deadlock detection works incorrectly with deadlocks that are not the cause of > the timeout. > -- > > Key: IGNITE-6527 > URL: https://issues.apache.org/jira/browse/IGNITE-6527 > Project: Ignite > Issue Type: Bug >Reporter: Vitaliy Biryukov >Assignee: Vitaliy Biryukov > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
