Release 15.0 withdraws nine fields from Session Logon

Release 15.0 removes ApplUsageOrders, ApplUsageQuotes, OrderRoutingIndicator, FIXEngineName, FIXEngineVersion, FIXEngineVendor, ApplicationSystemName, ApplicationSystemVersion and ApplicationSystemVendor from Session Logon (10000) and Session Logon Password-encrypted (19000). Deutsche Boerse published no replacement for them.

Breaking change: the matching setters and getters are gone from LogonRequest and LogonRequestEncrypted, and so are the three enumerations that existed only to serve them: ApplUsageOrders, ApplUsageQuotes and OrderRoutingIndicator. Delete the calls; nothing takes their place.

LogonRequest logon = new LogonRequest()
        .setDefaultCstmApplVerId(Handler.getDefaultCstmApplVerId())
        .setHeartBtInt(30000)
        .setPartyIdSessionId(partyIdSessionId)
        .setPassword(password);          // and nothing after it

The serialized Session Logon shrinks from 280 to 96 bytes, and the encrypted form to 752. Code that asserts either size, or that captured a logon frame and replays it, has to be updated.

OtherListener gains two callbacks

onTradingActionResponse and onUpdateReferencePricesResponse deliver the two new messages Release 15.0 files under “Other”.

Breaking change: classes that implement OtherListener directly will not compile until they implement both. The new TESInquireBoundaryPricesResponse is delivered through the inbound-message listener, as the other TES messages already are.

MMParameterDefinitionRequest is reordered on the wire

MMRiskLimitActionType now follows MarketSegmentID, TargetPartyIDSessionID and PctCount rather than preceding them. The Eurex change log does not mention this, and the Java API does not change: the setters, the getters and their order in source are all as they were, so nothing needs editing and nothing will fail to compile.

It matters only if your application handles the raw frame itself, by capturing it, replaying it, or decoding it with something other than this handler. Those frames are not interchangeable between 14.1 and 15.0.

OrderDeletionInstruction

A new enumeration, carried by the new fields on Party Action Report and Risk Notification and by TradingActionRequest.

Choosing a value for LogonTimeout

LogonTimeout bounds the wait for the exchange to answer a logon. When it elapses the attempt is abandoned, the handler reports DISCONNECTED, and it retries according to the reconnection settings. The default is 30 seconds.

HandlerSettings settings = new HandlerSettings();
settings.setLogonTimeout(10);        // seconds

Set it below whatever period your own application uses to reset or restart the handler. If your code tears the handler down every 15 seconds and the timeout is left at 30, the timeout never fires and the handler behaves as it did before this setting existed. Choose a value comfortably shorter than your own retry period and comfortably longer than a normal logon round trip to the exchange.

LogonTimeout bounds only the logon exchange. It is separate from Timeout, which bounds establishing the TCP connection, and from the heartbeat, which governs an established session.

init() now requires a completed shutdown()

Breaking change. init() fails with a HandlerException unless the handler's previous use has finished. connect(); disconnect(); init(); was accepted before and is refused now, because disconnect() ends a session while shutdown() is what ends the threads.

// Before
handler.connect(logon);
handler.disconnect();
handler.init(settings);      // accepted, and left two handler incarnations running

// Now
handler.connect(logon);
handler.disconnect();
handler.shutdown();          // let it return
handler.init(settings);

Calling init() on a fresh handler, or after a shutdown() that completed, is unaffected.

connect() on a connected handler now throws

Breaking change. connect() fails with a HandlerException when the handler is already connected, instead of accepting the call and abandoning it later. Applications that call connect() as an idempotent retry, or to switch credentials, must call disconnect() first or catch the exception.

A connect() issued from a handler-state listener cannot catch it usefully, because the dispatcher swallows exceptions thrown by listeners; such a listener should check getState() first.

A connect() issued immediately after a disconnect() is unaffected and still succeeds: the teardown is asynchronous, so that call is accepted and queued behind it.

connect() after shutdown() throws a different exception

Breaking change. It now fails with HandlerException, decided before the call touches your logon request. It previously failed with an unchecked RejectedExecutionException. Code that catches RejectedExecutionException around connect() must catch HandlerException instead.

Call init() to use the handler again after shutdown().

Discarded messages now reach the error listener

Messages still queued for sending when a session ends are discarded rather than carried onto the next session, and each one is reported to the error listener, preceded by a summary carrying the count. A session that ends with a deep backlog therefore produces a burst of onError callbacks, dispatched synchronously on the handler's main thread, so a slow listener will delay the teardown and any automatic reconnect that follows it. Applications that alert on onError should account for this.

Netty upgraded from 3.5.9.Final to 4.1.133.Final

The embedded Netty dependency has been upgraded from io.netty:netty:3.5.9.Final to io.netty:netty-all:4.1.133.Final. This brings security fixes and removes end-of-life Netty 3 from the transitive dependency tree.

Breaking change: The ReceivedBytesListener.onReceivedBytes method signature has changed:

// Before (Netty 3)
void onReceivedBytes(TemplateId templateId, org.jboss.netty.buffer.ChannelBuffer bytes);

// After (Netty 4)
void onReceivedBytes(TemplateId templateId, io.netty.buffer.ByteBuf bytes);

Update your import statements and replace ChannelBuffer with ByteBuf in any ReceivedBytesListener implementations. The io.netty:netty-all artifact must be on the classpath if you reference ByteBuf directly; it is already pulled in transitively by the handler.

New method ConnectionSettings.addAddressMapping

A new method addAddressMapping is added to ConnectionSettings to allow redirecting connections from one host/port endpoint to another.

Default TLS protocol changed to TLSv1.3

The default TLS protocol has been changed from TLSv1.2 to TLSv1.3. Eurex has decommissioned TLSv1.2 support. To override, use ConnectionSettings.setEnabledSslProtocols.

New HandlerSettings properties for sender and receiver thread affinity

To improve performance on NUMA and multi-socket systems, HandlerSettings now exposes setSendingThreadAffinity(int[]) and setReceivingThreadAffinity(int[]) methods that pin the respective I/O threads to specific CPU cores.

Become ready to Introduction of Release 14.1 (D0002) on 23 March 2026

Please see “Change Log” section in Enhanced Trading Interface Derivatives Message Reference version 14.1 from 23 March 2026.

Become ready to Introduction of Release 14.0 (D0002) on 1 September 2025

Please see “Change Log” section in Enhanced Trading Interface Derivatives Message Reference version 14.0 from 13 August 2025.

New method Handler.getLicense() that returns the license information

To simplify the license verification process, a new method Handler.getLicense() is introduced.

Become ready to Introduction of Release 13.1 (D0002) on 31 March 2025

Please see “Change Log” section in Enhanced Trading Interface Derivatives Message Reference version 13.1 from 7 March 2025.

Add Password Encryption

The Eurex exchange provides a public key that traders use to encrypt their passwords before sending them over the network. The Handler now supports password encryption. To encrypt a password, use the Handler.encryptPassword method and new Handler.connect method that accepts LogonRequestEncrypted.

Remove HandlerSettings's properties

The following properties are removed from the HandlerSettings class:

• gatewayPassword;
• partyIdSessionId.

Set these values directly in the LogonRequest.

Become ready to Introduction of Release 13.0 (D0002) on 9 September 2024

Please see “Change Log” section in Enhanced Trading Interface Derivatives Message Reference version 13.0 from 9 September 2024.

Become ready to Introduction of Release 12.1 (D0002) on 11 March 2024

Please see “Change Log” section in Enhanced Trading Interface Derivatives Message Reference version 12.1 from 11 March 2024.

Become ready to Introduction of Release 12.0 (D0003) on 31 October 2023

Please see “Change Log” section in Enhanced Trading Interface Derivatives Message Reference version 12.0 from 31 October 2023.

Become ready to Introduction of Release 12.0 on 11 September 2023

Please see “Change Log” section in Enhanced Trading Interface Derivatives Message Reference version 12.0 from 23 August 2023.

Become ready to Introduction of Release 11.1 (D0002) on 27 February 2023

Please see “Change Log” section in Enhanced Trading Interface Derivatives Message Reference version 11.1 from 17 March 2023.

SessionListener is changed

Instead of single SessionListener interface the Handler offers three new interfaces: InboundMessageListener, OutboundMessageListener, and ReceivedBytesListener.

ReconnectionSettings.Mode is removed

AdminListener is changed

Recently added onOutboundMessage and onInboundMessage are moved to the new SessionListener interface.

Return type of Message.getTemplateId() is changed

This method now returns TemplateId instead of short.

Become ready to Introduction of Release 10.1 (D0002) on 27 June 2022

Please see “Change Log” section in Enhanced Trading Interface Derivatives Message Reference version 10.1 from 13 April 2022.

AdminListener is changed

Please rename onMessageSending to onOutboundMessage and add new callback onInboundMessage. The reference tickets are JAVAEUREXETI-44 and JAVAEUREXETI-46.