Version 1.52.0 released

Aeron 1.52.0: Easier to run, lower latency in replay workloads

Aeron 1.52 focuses on usability. This post covers the headline changes: improvements to how you configure, log, and inspect Aeron in production, and a fix for a latency problem in replay workloads that was difficult to diagnose without digging into driver internals. For the full list of changes, see the release notes.
 

Aeron 1.52.0 operational improvements

• CPU affinity:
  Thread pinning is one of the things that makes Aeron fast. It is also one of the things that has historically made Aeron hard to operate. Getting a well-tuned deployment required detailed knowledge of hardware topology, careful manual configuration, and no real feedback if you got it wrong – Aeron would accept your configuration and perform poorly without telling you why.
  
  That picture gets harder in dynamic and container environments. Systemd, Docker, Nomad and Kubernetes assign CPUs dynamically through cgroups, and Aeron’s C media driver previously had no understanding of this model. CPU indices were always treated as absolute values, which breaks under dynamic cpuset constraints. Workarounds existed, but they took significant effort and expertise to get right.
  
  In 1.52, the C media driver gains native cpuset support: CPU indices can now be interpreted relative to the current cpuset, so your configuration works the same way whether you’re on bare metal or on cloud inside a container. The driver also manages its own base affinity rather than relying on external tooling, and will now warn you at startup if your configuration is likely to hurt performance – threads crossing L3 cache boundaries, non-whole CPU cores, or different CPU clusters. Getting a performant deployment should be considerably faster and require considerably less specialist knowledge than before.
  
  For Java users: The C media driver is a common production choice. Java clients connect to it transparently via shared memory, so these improvements apply without any code changes.
• Log rotation:
  Aeron logging is off by default for performance reasons – counters are available for monitoring purposes and are the right tool for production observability. When you do need logging – during initial rollout, active debugging, or a period of instability – you’ve had to manage disk space yourself or turn it off again quickly.
  
  1.52 adds size-based log rotation via the aeron.event.log.file.max.length property (only relevant when aeron.event.log.filename is also set). When the log file reaches the configured length, it is renamed to <filename>.1 (incrementing if that name already exists) and a new file is started – the same pattern used by logrotate. Default behaviour is unchanged; if you don’t set the property, there is no rotation.
  
  Full configuration reference: Monitoring and Debugging – Debug Logging
• LogInspector CLI:
  LogInspector is the tool for reading Aeron log files. Previously, invoking it required passing Java system properties on the command line – the kind of thing that works fine if you already know exactly what you’re doing, but creates unnecessary friction otherwise. It also meant maintaining bash wrappers that didn’t work on Windows.
  
  1.52 replaces this with LogInspectorCli, a proper native Java CLI consistent with the patterns used elsewhere in Aeron tooling. It takes named flags, has a --help endpoint, and works on Windows and Linux.

Latency

No more conductor stalls during log buffer operations

Creating and removing log buffers can take hundreds of milliseconds for large term buffers. Previously, both operations happened on the driver conductor thread. While the conductor was waiting on a file operation, it stopped updating stream counters – and without updated counters, senders and receivers cannot make progress. The result was latency spikes that were difficult to attribute without digging into driver internals.

In 1.52, log buffer creation and removal are moved to a background thread (NativeResourceAgent). The conductor thread is no longer blocked by either operation, and stream counters continue to update normally throughout.
This is most visible in workloads that involve replay, or that use large term buffers. The stall was proportional to term buffer size – for a 64MB term buffer the unlink alone could take around 20ms.
 
For detailed release notes on Aeron 1.52.0, please visit Github >>