[
https://issues.apache.org/jira/browse/ARTEMIS-5851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim updated ARTEMIS-5851:
---------------------------
Description:
h3. Sequence of bug:
# Client calls {{xa_start(xid)}} — transaction created in {{ResourceManager}}
# Server timeout occurs — {{TxTimeoutHandler}} removes transaction from
{{ResourceManager}}
# Client sends message with original {{transactionId}} (unaware of timeout)
# Server's {{lookupTX()}} returns {{null}} (transaction no longer exists)
# Message is processed with {{tx = null}} — *auto-committed silently*
# Client calls {{xa_end(xid)}} — receives {{XA_RBTIMEOUT}} error
h3. Root Cause
In {{{}OpenWireConnection.java{}}}, method {{processMessage()}} (lines
1744-1770):
java
Transaction tx = lookupTX(messageSend.getTransactionId(), session);
session.getCoreSession().resetTX(tx); // tx = null after timeout
session.send(producerInfo, messageSend, sendProducerAck); // auto-commit!
{{}}
The validation that exists in {{processMessageAck()}} is missing in
{{processMessage()}} :
java
// This check exists in processMessageAck() but NOT in processMessage():
if (ack.getTransactionId() != null && tx == null) {
throw new IllegalStateException("Transaction not started, " +
ack.getTransactionId());
}\{{}}
h3. Proposed Fix
Add validation to {{{}processMessage(){}}}, so when client sends TransactionId,
it expects actions inside transaction, not auto-committed actions:
java
Transaction tx = lookupTX(messageSend.getTransactionId(), session);
if (messageSend.getTransactionId() != null && tx == null) {
throw new IllegalStateException("Transaction not started or timed out: " +
messageSend.getTransactionId());
}
session.getCoreSession().resetTX(tx);
h3. Current bug impact on:
* Violates XA transaction atomicity guarantees
* Messages silently committed outside of transaction scope
* No error reported to client until {{xa_end()}} is called
was:
h3. Sequence of bug:
# Client calls {{xa_start(xid)}} — transaction created in {{ResourceManager}}
# Server timeout occurs — {{TxTimeoutHandler}} removes transaction from
{{ResourceManager}}
# Client sends message with original {{transactionId}} (unaware of timeout)
# Server's {{lookupTX()}} returns {{null}} (transaction no longer exists)
# Message is processed with {{tx = null}} — *auto-committed silently*
# Client calls {{xa_end(xid)}} — receives {{XA_RBTIMEOUT}} error
h3. Root Cause
In {{{}OpenWireConnection.java{}}}, method {{processMessage()}} (lines
1744-1770):
java
Transaction tx = lookupTX(messageSend.getTransactionId(), session);
session.getCoreSession().resetTX(tx); // tx = null after timeout
session.send(producerInfo, messageSend, sendProducerAck); // auto-commit!
{{}}
The validation that exists in {{processMessageAck()}} is missing in
{{processMessage()}} :
java
// This check exists in processMessageAck() but NOT in processMessage():
if (ack.getTransactionId() != null && tx == null) \{
throw new IllegalStateException("Transaction not started, " +
ack.getTransactionId());
}{{}}
h3. Proposed Fix
Add validation to {{{}processMessage(){}}}, so when client sends TransactionId,
it expects actions inside transaction, not auto-committed actions:
java
Transaction tx = lookupTX(messageSend.getTransactionId(), session);
if (messageSend.getTransactionId() != null && tx == null) \{
throw new IllegalStateException("Transaction not started or timed out: " +
messageSend.getTransactionId());
}
session.getCoreSession().resetTX(tx);
h3. Current bug impact on:
* Violates XA transaction atomicity guarantees
* Messages silently committed outside of transaction scope
* No error reported to client until {{xa_end()}} is called
> When an XA transaction times out on the server side, subsequent client
> operations are silently auto-committed instead of being rejected
> ---------------------------------------------------------------------------------------------------------------------------------------
>
> Key: ARTEMIS-5851
> URL: https://issues.apache.org/jira/browse/ARTEMIS-5851
> Project: Artemis
> Issue Type: Bug
> Components: OpenWire
> Affects Versions: 2.51.0
> Reporter: Maxim
> Priority: Major
>
> h3. Sequence of bug:
> # Client calls {{xa_start(xid)}} — transaction created in {{ResourceManager}}
> # Server timeout occurs — {{TxTimeoutHandler}} removes transaction from
> {{ResourceManager}}
> # Client sends message with original {{transactionId}} (unaware of timeout)
> # Server's {{lookupTX()}} returns {{null}} (transaction no longer exists)
> # Message is processed with {{tx = null}} — *auto-committed silently*
> # Client calls {{xa_end(xid)}} — receives {{XA_RBTIMEOUT}} error
> h3. Root Cause
> In {{{}OpenWireConnection.java{}}}, method {{processMessage()}} (lines
> 1744-1770):
>
> java
> Transaction tx = lookupTX(messageSend.getTransactionId(), session);
> session.getCoreSession().resetTX(tx); // tx = null after timeout
> session.send(producerInfo, messageSend, sendProducerAck); // auto-commit!
> {{}}
>
> The validation that exists in {{processMessageAck()}} is missing in
> {{processMessage()}} :
> java
> // This check exists in processMessageAck() but NOT in processMessage():
> if (ack.getTransactionId() != null && tx == null) {
> throw new IllegalStateException("Transaction not started, " +
> ack.getTransactionId());
> }\{{}}
> h3. Proposed Fix
> Add validation to {{{}processMessage(){}}}, so when client sends
> TransactionId, it expects actions inside transaction, not auto-committed
> actions:
> java
> Transaction tx = lookupTX(messageSend.getTransactionId(), session);
> if (messageSend.getTransactionId() != null && tx == null) {
> throw new IllegalStateException("Transaction not started or timed out: " +
> messageSend.getTransactionId());
> }
> session.getCoreSession().resetTX(tx);
> h3. Current bug impact on:
> * Violates XA transaction atomicity guarantees
> * Messages silently committed outside of transaction scope
> * No error reported to client until {{xa_end()}} is called
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
