Changelog

All notable changes to 3.14.0 Java API will be documented in this file.

The 'name' of the API is 3.14.0 and will never change.

[3.14.0-600] - Dec 17 2019

• [ADDED] - New ModifyOrder overload to pass optional order parameters exactly like the SubmitOrder methods.

[3.14.0-500] - Dec 12 2019

• [ADDED] - New ZeroGC MFClient submitOrder method with both minAmount and 'parameters' parameters.
• [IMPROVED] - Small improvements to performance and reduction in generated garbage during Order sending with parameters.
• [ADDED] - Increased the single message max size from 32K to 128K to handle the larger CME Config messages.

[3.14.0-400] - Nov 22 2018

• [ADDED] - Regular MFClient has a non-blocking connect method to be used in conjunction with processEvents.
• [ADDED] - ProcessEvents sample created
• [FIXED] - processEvents now returns reliably after processing the current input buffer

[3.14.0-320] - Oct 18 2018

• [ADDED] - Potential minor-breaking change to latency calculations. PingTimes timestamps generated at the client-side are now nano precision using System.nanoTime. This means they are no longer comparable to the server timestamp. The advantage is you can measure the round-trip latency in nanoseconds. If you were using the milliseconds ping times in calculations this will likely break your usage. The reason for this change is clients are close to or sub 1 ms for server to client latency and the nano precision is required.

[3.14.0-310] - May 30 2018

• [ADDED] - Exposed CancelOrder method where client provides the cancelId, orderId, and clOrdId - in both zerogc and regular MFClients.

[3.14.0-300] - Apr 11 2018

• [ADDED] - Unhandled exceptions thrown in the client callbacks are now caught and properly logged. Additionally these will also cause the MFClient to stop dispatching and disconnect from the server.

• [FIXED] - Issue with ZeroGC issue handling initial heartbeats introduced in [3.14.0-203]

[3.14.0-203] - Dec 18 2017

• [FIXED] - Issue with overwriting of internally buffered data. The issue was that if there was any data in the buffer when a new message needs to be written out - the originally buffered data was overwritten. This caused data corruption and server disconnection. In practice this only happens to high-volume market making clients who send large quote messages extremely quickly. What will happen now is the client will disconnect with an error message unless the new stay connected JVM flag is used.

• [ADDED] - 3 optional JVM args to control messaging behavior:

  • MFStayConnectedAfterSendBufferFull {true|false default: false} - if set to true, then if the send buffer is full, the API will not disconnect. The message will not be sent and the send call will report APIResult.BUFFER_FULL. You will have to attempt to resend that or another message. There is no callback available to inform you that the buffer is empty and sending can continue.
  • MFTcpReceiveBufferBytesHint {>0} - if provided, will try to set the TCP Receive buffer size to the value. The actual value set is OS dependent but will in practice be close to the set value. The actual used value will be logged whenever a socket is created.
  • MFTcpSendBufferBytesHint {>0} - if provided, will try to set the TCP Send buffer size to the value. The actual value set is OS dependent but will in practice be close to the set value. The actual used value will be logged whenever a socket is created.

• [FIXED] - ZeroGC MFClient and MFMarketMaker now implement #getPingTimes. If useHeartbeats is set to true (by default it is), the the client will periodically send a message the server and the server will respond. The timestamps of these messages are stored and available to the user.