[
https://issues.apache.org/jira/browse/AMQCPP-648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17029026#comment-17029026
]
Timothy A. Bish commented on AMQCPP-648:
----------------------------------------
The XA support in the C++ was an experiment that never saw any real use or much
testing, I'd advise against using it especially in a production environment.
> Invalid cast in ConnectionState object in ConnectionStateTracker called from
> FailoverTransport::oneway() while initiating an XA transaction
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: AMQCPP-648
> URL: https://issues.apache.org/jira/browse/AMQCPP-648
> Project: ActiveMQ C++ Client
> Issue Type: Bug
> Components: Transports
> Affects Versions: 3.9.5
> Reporter: Sven Bovin
> Assignee: Timothy A. Bish
> Priority: Major
>
> From a C application we use the ActiveMQ-CPP libraries (version 3.9.5) to
> interact with ActiveMQ Classic 5.15.11.
> Our application connects to a broker using the failover transport.
> When starting an XA transaction, we first create an XID (an object of type
> XATransactionId) and use it to start the XA transaction with the
> XAResource::start method. Control then flows through several layers to arrive
> in the FailoverTransport::oneway method where a state tracker is called. The
> state tracker leads to a ConnectionStateTracker::processBeginTransaction
> method that grabs our XID (an XATransactionId) and tries to cast it to a
> LocalTransactionId. Both XATransactionId and LocalTransactionId inherit from
> TransactionId, but an XATransactionId is obviously not a LocalTransactionId
> and the cast fails. Our attempt to start an XA transaction therefore also
> fails.
> Using tcp transport instead of failover allows our code to correctly start
> the XA transaction but is not a viable solution for production use.
> Is what we observed (impossible to start an XA transaction while using
> failover) the expected behaviour (and if so, what is the rationale for it) or
> is it a bug in the library?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
