Introduction
In the Chronicle 25 release series, we are pleased to announce that we officially support Java 21. This release also includes a large number of performance enhancements, improvements and bug fixes. In addition to moving our libraries forward we also continue to improve our testing – driving up our test coverage and consolidating a robust, productive and rock-steady low latency Java platform.
As with all our recent releases you will need explicit –add-opens JVM args to ensure Chronicle code continues to work with the Java Module System. The add-opens remain unchanged since previous releases and can be found here.
Interested in tracking all our releases? Please check out our release notes generator and subscribe to release notifications.
What’s new?
Chronicle Queue
hugetlbfs support comes to Java Chronicle Queue
Chronicle Queue x.25 for Java gains feature parity with its C++, Rust, and Python counterparts by introducing hugetlbfs support on Linux. Hugetlbfs is a file system designed for allocating memory in huge pages that benefits workloads dealing with frequently accessed, large datasets. This technique is particularly valuable in low-latency environments where it can reduce transaction lookaside buffer (TLB) pressure and memory management overhead.
When discussing hugepages this can typically mean hugetlbfs or Transparent Huge Pages (THP). For Chronicle Queue, hugetlbfs offers finer control, enabling Chronicle Queue to store queue data within a hugetlbfs filesystem and tune the page size for each queue independently. This flexibility allows for optimal performance based on specific queue requirements. For ease of use, Chronicle Queue can automatically detect hugetlbfs mounts and adjust its behavior for further optimisation.
Chronicle Queue Enterprise
Replication performance
We addressed how Chronicle Queue handles a partial write, which can occur during an ungraceful shutdown. Chronicle Queue Enterprise is rigorously tested with chaos monkey tests designed to flush out corner cases surfaced by poor network connections, and ungraceful shutdown of components. Previously, a very comprehensive “paranoid” append operation caused a bottleneck on replication nodes. By optimising partial write recovery we’ve now eliminated this bottleneck. Our internal testing demonstrates up to a significant ~40% improvement in simple 1-to-1 replication throughput. Results may vary depending on your individual set up so we invite feedback on the performance in this area.
Fine tuning of replication acknowledgement in Chronicle Queue Enterprise
Chronicle Queue Enterprise replication keeps your queue data synchronized across servers and data centres with minimal latency. This product offering is crucial for large deployments, ensuring data consistency and high availability. It uses acknowledgements to verify successful data transfer and now lets you configure how many replication messages can be in flight at any one time. This “in-flight message count” allows you to balance performance and risk based on your specific needs. By adjusting this setting you can potentially achieve significant speed-ups in your application. This option is available in Chronicle Queue Enterprise and can be found on the ExcerptTailer#acknowledgedIndexReplicatedCheck method.
Archiving utility
In our x.25 release, we are pleased to introduce a new feature that will streamline the process of managing and backing up queue roll cycle files: the ArchiveRollFiles Utility. Archiving old queue files allows you to keep a historical record of your system, enabling you to replay historical data and investigate previous events deterministically.
With this built-in Archive Utility, users no longer need to create and run manual scripts with fiddly logic to track which files are open. The utility provides an automated solution to archive and delete old files based on their last modified time, ensuring data integrity and availability by only archiving files that are not currently in use. For further information on how to utilize this feature, please see the documentation on the User Portal.
Further performance enhancements
We have also shipped improvements to TLS support for large messages and improved network performance over high latency connections. Chronicle Map Enterprise replication has been re-written and is now faster with fewer failure modes.
Chronicle Services
Performance tuning
Chronicle Services now ships with advanced tooling to diagnose and report on operating system performance tuning issues on Linux systems. It checks for issues such as non-optimal scaling governors, C-States, kernel command line parameters and more. When coupled with other approaches such as CPU isolation using Chronicle Tune and thread pinning using Java-Thread-Affinity this can help unlock the full low latency potential of your Chronicle Services application.
Chronicle Tune tackles low-latency challenges for microservices by offering a user-friendly interface to configure critical low-latency tuning settings on Linux. It grants precise control over CPU allocation, interrupt handling, and other performance factors traditionally managed through complex tools. This fine-tuning ensures your system prioritises responsiveness and minimises delays, optimising performance for low-latency microservices.
Services Monitoring
There have been multiple improvements to Services Monitoring including: bug fixes in the monitoring service around opening read only queues; fixing a bug with queue stat reporting and enabling services performance timestamping to include FIX sessions.
Chronicle FIX
The Chronicle FIX trading engine has received significant updates focused on enhancing performance, reliability, and usability. The engine’s message parsing is now faster and more efficient further reducing latency. Replay functionality has been enhanced for quicker recovery from interruptions, and overall stability has been improved, making the engine more robust under heavy use. Configuration has been simplified by removing obsolete settings, and connection handling has been improved. Other noteworthy improvements include:
- Prometheus monitoring gateway
- Numerous performance improvements
- More options for efficient logging of incoming FIX messages
- More flexible parsing options for repeating groups
- Greater resilience in the face of badly behaved FIX counterparties
- Improvements to dynamic configuration of the engine
- Improvements to YamlFixTester testing framework
- Additional functionality for dynamic fields (fields not recorded in the schema)
- Increased flexibility for runtime ITCH message parsing
- Improvements to TLS support for large messages
- Improvements to network performance over high latency connections
Chronicle Bytes
Chronicle Bytes in Java 9 and above includes a speed boost for comparing Bytes instances. The update leveraged special JVM intrinsics via vectorizedMismatch to potentially use optimised instructions for faster comparisons. This optimised check works for various Bytes types, on or off-heap memory. Version 25 includes a bounds-checking bug fix and over 40 new tests for this functionality. Enjoy faster Bytes equality checks!
Our release methodology
We’re often asked questions about our release methodology – our approach to EA releases draws the most questions of all. In our releases, EA stands for Early Access. Approximately every six months, we cut a new major release branch. This allows us to evolve the APIs of our products and still maintain versions with the old APIs until they are no longer supported. This provides continuity for those who need it, and faster change for those who opt-in for it.
When we first cut a new release branch we include the “ea” moniker in the release names, for example 2.26ea1. We keep releasing with this moniker until we consider the branch fully stable, at which point the “ea” moniker is removed, and the first official stable release of that release series is made. To put this into context, the x26 release was first released in May 2024; we anticipate this will evolve into a stable release in October 2024, coinciding with when the next early access release series will begin. Stable release access is offered to customers with a commercial agreement in place. For our open-source offerings all of our EA releases are available on maven central.
At any one time, it’s possible that we will support the current major release series and two older release series. At the time of writing, we have released x.26 early access but ship x.25 and x.24 stable release series regularly. Customers who receive support on these branches, and the stable release series will receive regular updates and back-porting of bug fixes. Note that many of the features listed in the article have also been backported to our stable branches for commercial customers so are available in EA and stable versions.
You can find more information about our versioning methodology in the OpenHFT repository on Github. If you’d like to learn more about getting access to our stable release series please contact us.
Co-author: James McSherry
