What’s new in Aeron: Highlights from the London Meetup 2026

At the recent Aeron Community MeetUp in London, Aeron engineers, Dmytro Vyazelenko and Nadia Aina walked the audience through the most significant updates that have landed in Aeron over the past two releases — 1.49.0 (October 2025) and 1.50.0 (January 2026) — and previewed an upcoming open-source feature: Persistent Subscriptions.

This blog summarises the headline changes from their talk. You can watch the full talk recording to view the code samples and configuration snippets and gain deeper technical context.

Discover Aeron 1.49.0 and 1.50.0 enhancements including:

• Named Archive & Cluster clients
• Response channels IPC media support
• Standalone C++ API removal
• Specify interfaces by name
• Zero NAK delay for non-reliable streams
• Why ReplayMerge needs a companion
• The benefits of Persistent Subscriptions

Aeron 1.49.0: better visibility into connected clients

Aeron Archive and Aeron Cluster Clients

A recurring pain point reported by Aeron users has been determining which clients are connected to an Aeron Archive or Aeron Cluster, particularly when sessions time out and operators need to figure out where they originated. Previously, a counter exposed only the number of connected clients, with no way to attribute them to specific machines or services.

Aeron 1.49.0 addresses this challenge by introducing named clients for both Aeron Archive and Aeron Cluster, alongside per-session counters that expose meaningful metadata.

• Named Archive clients: a name can be set via AeronArchive.Context#clientName(String) API or the aeron.archive.client.name system property. Each connected control session is then exposed through a counter that includes the assigned name, Aeron version, commit hash, source identity, session ID, and archive ID.
• Named Cluster clients: the equivalent capability for Cluster, configured through AeronCluster.Context#clientName(String) API or aeron.cluster.client.name. Each connected cluster session is then exposed through a counter that includes the assigned name, Aeron version, commit hash, source identity, session ID, and cluster ID.

The result is significantly faster triage. Operators can see at a glance which gateway or service is connecting, which Aeron version it is running, and where it originates from — useful both for day-to-day debugging and for spotting stragglers still pinned to old releases.

Aeron response channels now work over IPC

Response channels were originally introduced as a UDP-only feature, but in 1.49.0, they were extended to work over IPC as well, with the same correlation-ID wiring on both sides. The only difference is that IPC channels don’t require a control address; the rest of the setup mirrors the UDP case. You can find out more about the full subscriber and publisher snippets in the full recording.

Aeron 1.50.0: API cleanup and operator-friendly tweaks

The January 2026 release brings several smaller but meaningful changes.

Standalone C++ API removed

The standalone C++ API, deprecated since 1.47.0, has now been removed. Users still using the C++ API should migrate to the Aeron C++ Wrapper, which sits on top of the C API and is API-compatible for the vast majority of use cases. A small set of utilities — such as direct log buffer access — is not part of the wrapper and must be accessed through the C API.

Specifying interfaces by name

Selecting a NIC for multicast traffic previously required CIDR notation:

• aeron:udp?endpoint=localhost:5050|interface=192.168.0.1/24

Interfaces can now be referenced by name:

• aeron:udp?endpoint=localhost:5050|interface={eth0}

This is particularly useful in environments such as Kubernetes, where interface names are predictable, but IP addresses are not known in advance.

Zero NAK delay for non-reliable streams

Aeron streams can opt out of reliability via reliable=false, which is appropriate for workloads such as observability data or certain market data feeds. Loss recovery normally applies an initial NAK delay before asking the publisher to retransmit, in order to avoid NAK storms. For non-reliable streams, no NAK is ever sent — loss is replaced with padding — yet the delay was still being applied, adding latency for no benefit. From 1.50.2 onwards, that delay has been eliminated for non-reliable streams, so loss is turned into padding immediately.

Aeron 1.51.0: Persistent Subscriptions
An alternative to ReplayMerge

The second half of the session introduced Persistent Subscriptions, an open-source feature sponsored by Nonco that was added to the open-source repository in 1.51.0. It sits alongside the existing ReplayMerge functionality in Aeron Archive rather than replacing it.

Why ReplayMerge needs a companion

ReplayMerge enables a seamless transition from a replay stream to a live stream, allowing late-joining or recovering applications to consume historical data first and then continue on the live feed. It works well in the deployment model it was designed for: many small machines, each running a dedicated service.

Modern deployments tend to look different — fewer, larger machines with co-located services. In that world, ReplayMerge has three notable limitations:

• It only works with remote Archives, so the catch-up window can’t be shrunk by placing the Archive next to the subscriber.
• It can’t spy on local publishers, forcing a network round-trip even when publisher and subscriber are co-located.
• Its configuration is complex, and the API has a reputation for being hard to use.

ReplayMerge is in production use, and changing its implementation would break that API. Persistent Subscriptions is therefore a new, parallel implementation.

The benefits of Persistent Subscriptions

Persistent Subscriptions is implemented entirely on top of client-side APIs, rather than partially in the media driver as ReplayMerge is. That choice is what unlocks the rest:

• Support for IPC, unicast, and spies, addressing the co-location story.
• A familiar configuration and API surface, modeled on a standard Aeron subscription.
• Automatic fallback to replay if a slow consumer is kicked off the live stream by flow control — repeated as many times as necessary, with no application-level handling required.

Under the hood, two subscriptions are used: one for replay and one for live. The implementation consumes from replay, attaches the live subscription at the right moment, continues replaying until the streams converge, and then transparently switches over. To the application, it looks like a single continuous stream.

Two technical challenges receive particular attention in the full recording:

• Choosing when to add the live subscription — too early and the catch-up window grows unbounded; too late and the streams may not converge.
• Handling fragmented messages across the switch is solved by a custom fragment assembler, so the default assembler’s drop behavior never surfaces to user code.

The main trade-off, raised during the Q&A, is a slightly heavier memory footprint: two log buffers and two underlying images instead of one. Where memory is constrained, ReplayMerge remains a reasonable choice.

Watch the full session now

This blog just shares some of the key areas our speakers delve into. The recording includes the full code samples for response channels over IPC, the step-by-step walkthrough of the Persistent Subscriptions handover, and a short Q&A.

1. 

   Dmytro Vyazelenko Performance Engineer
   Adaptive | Aeron

   LinkedIn profile

   Dmytro is a Performance Engineer on Adaptive’s Aeron core team, specialising in low-latency Java, distributed systems, and mission-critical messaging for capital markets and payments clients.

2. 

   Nadia Aina Full Stack Java Developer
   Adaptive | Aeron

   LinkedIn profile

   Nadia Aina is a Full-Stack Java Developer at Adaptive, working in the Aeron product team. She joined via Adaptive’s Early Careers Programme and now contributes to Aeron’s open-source releases and community talks.