Eurex Clearing
Dear Clearing Member,
As announced with Eurex Clearing Newsflash from 10 September 2020, the upgrade of FpML, Trade Entry and Margin Calculator Interfaces from qpid C++ to qpid Java for Members using the AMQP brokers will be performed on 21 November 2020 in the production environment.
With this newsflash, Eurex Clearing provides further information on this upgrade and clarifies the differences between Java Broker and C++ Broker from client perspective to ease the process.
1. Exchanges do not support flow-control
The new Java broker allows to define flow control only on queues, whereas Eurex Clearing only supports a discard or reject policy for un-routable messages. This means that if the queue is full, the sender will either receive an error or the message will be silently rejected.
Therefore, the behavior of the request mechanism on the Java broker differs in how the member (requestor) is notified when a request queue is full.
Broker | Synchronous sender | Asynchronous sender | ||
MRG-M | Sender is blocked | The message is sent, but confirmation from the broker does not come until the flow control is cancelled. | ||
Java | Sender receives rejection error – based on the implementation the connection can be closed, which leads to a disconnection of the client | Sender asynchronously receives rejection error – based on the implementation the connection can be closed, which leads to a disconnection of the client |
IMPACT: The change will affect every client if the EurexOTC Clear backend system is not able to consume requests fast enough.
2. Client ID
The new Java broker strictly requires an unique "client ID" to establish connection. It is impossible that two connections are used with the same client ID.
If the client ID is not specified, the broker will assign a unique value to the client.
IMPACT: This change will affect only those who use JMS and specify the client ID manually.
3. Correlation ID
To use the correlation ID selector for Java Broker consumer, the keyword JMSCorrelationID must be used instead.
The selector amqp.correlation_id = {UUID} will change to JMSCorrelationID = {UUID}
IMPACT: The change will affect only those clients who are using selectors. NOTE: This change is not backwards compatible.
4. Delivery settlement (Message acknowledgement)
On high load, the C++ broker handles deliveries continuously, whereas Java broker handles deliveries in batches of 5.
IMPACT: No impact on performance nor functionality, only looks different when debugging a client application.
The following table summarizes whether the above changes require a code change from client side or are backwards compatible.
Change | Requires code change | Backwards compatible | ||
Exchanges do not support flow-control | Depends on current client implementation | Depends on current client implementation | ||
Client ID | Only if non-unique client ID is used | Yes | ||
Correlation ID | Yes | No | ||
Delivery settlement (Message acknowledgement) | No | N/A |
For further details, please refer to the "Eurex Clearing Messaging Interfaces - Connectivity B: AMQP Programming Guide, V. 2.1", which is available for download on the Eurex Clearing website under the following link:
Tech > C7 > System documentation > Eurex Clearing Interfaces
If you have any questions or require further information, please contact your Technical Key Account Manager via your VIP number or send an e-mail to cts@deutsche-boerse.com.
Kind regards,
Your Client Services Team
How to keep up with news? Get here the latest Eurex updates - fast and easy: Eurex App, LinkedIn, YouTube or visit our website.

Recipients: | All Clearing Members, Basic Clearing Members, FCM Clearing Members, Disclosed Direct Clients of Eurex Clearing AG and vendors and other affected contractual parties |
Target groups: | Front Office/Trading, Middle + Back Office, IT/System Administration, Treasury |
Contact | cts@deutsche-boerse.com or your Technical Key Account Manager |
Web: | www.eurex.com/ec-en/ |