Streaming Servers with Apache MINA and Groovy™ 6

A simple line-based protocol over TCP:

Server pushes look like:

The ticks themselves are produced by a stub FakeTickSource for now. In a follow-up post we will replace that stub with real data fetched in parallel from a fleet of sources — but the protocol, broadcast machinery, and per-session async logic will not need to change.

A MINA server only needs five concepts:

The entire server boot is about ten lines:

So far, so MINA. The interesting bit is what we put inside TickerHandler.

A MINA IoHandler traditionally does all of its work inside messageReceived. The chat example shipped with MINA is a good representative — it carries the entire chat protocol inside one big switch over the parsed command, with shared state held in synchronized sets:

That works, and for many years it was the right shape. But every concurrent feature — broadcast, shared user list, session lifecycle — ends up either as synchronized collections or as more callbacks. Adding a downstream call (e.g., look up the user’s permissions over HTTP) means either blocking a precious NIO thread or chaining yet more callbacks.

We will refactor along a single principle: the handler does nothing except shuttle events into a channel, and the actual protocol runs as one straight-line async task per session.

Here is the entire MINA-facing surface of our server:

That is everything we will ever write against IoHandler. The handler now contains zero protocol logic. Each connected client gets a per-session AsyncChannel (a Go-style buffered channel) and a single async { } task that drives the protocol from start to finish.

A few things worth noting:

With the bridging in place, here is the entire protocol — all the conversation logic that the bundled MINA chat handler scattered across callbacks now lives in one method:

A plain for loop consumes the inbox as it is filled by messageReceived — AsyncChannel exposes itself as a blocking iterable, so the loop reads top-to-bottom and exits when the channel is closed. The whole loop runs inside AsyncScope.withScope { …​ } so any subscription tasks we launch underneath (see the next two sections) inherit a structured lifetime: when the loop exits — on QUIT, on the client disconnecting, or on any exception — the scope guarantees every child task has finished or been cancelled before run() returns.

QUIT is one line: send BYE, ask MINA to close on flush, and the resulting sessionClosed callback closes the inbox channel, which terminates the for loop. Compare that with calling session.closeNow() from deep inside a callback chain.

The price feeds and last-tick cache are shared across every session. The traditional answer is Collections.synchronizedMap or some other mutex dance. Groovy 6’s @ActiveObject turns ordinary class methods into messages on a serialised mailbox, so we get race-free state without writing synchronized once:

@ActiveMethod calls are routed through the registry’s internal actor, so two threads can freely call publish and subscribe at the same time without us thinking about locks.

BroadcastChannel is the other star of this section. Unlike a plain AsyncChannel (which delivers each value to one consumer), a broadcast delivers every value to every subscriber. Calling asPublisher() adapts it to the JDK java.util.concurrent.Flow.Publisher interface, which for await consumes natively. The same plumbing works against any reactive stream — a Reactor Flux (via the groovy-reactor module) or an RxJava Observable (via groovy-rxjava) would slot in unchanged.

Each SUBSCRIBE spawns a small async task that consumes the broadcast for the requested symbol and writes ticks to the session:

UNSUBSCRIBE flips an AtomicBoolean; the per-symbol loop notices on its next tick, breaks, and for await cancels the underlying subscription on the way out.

Two pieces of the new toolkit are doing the heavy lifting here:

QUOTE AAPL,GOOG,MSFT,TSLA asks for one snapshot per symbol. The natural shape is to fire all the lookups in parallel and join on the results — which is exactly what AsyncScope is for:

The scope owns the lifetime of the per-symbol tasks. If any single lookup blows up, the others are cancelled before the scope exits — no leaked tasks, no half-finished work, no manual CompletableFuture.allOf plus exception-handling boilerplate. With virtual threads, fanning out over hundreds of symbols costs essentially nothing.

For now the ticks come from a stub: one async task per symbol drips a randomly walked price into the registry every 200 ms.

We pulled the random number generator from Apache Commons RNG Simple 1.7 (also a fresh release): UniformRandomProvider is a drop-in replacement for java.util.Random with the same nextInt(n) shape, but backed by faster, statistically stronger algorithms — in this case the recommended general-purpose XO_RO_SHI_RO_128_PP.

In a follow-up post we will replace this stub with real prices fetched in parallel from a fleet of sources — using Apache MINA SSHD as a client, parallel collections, and Pool.virtual(). The consumer side — everything we built above — does not change at all.

The repository ships a TickerServer.groovy script that boots the acceptor on an ephemeral port, opens an in-process socket client, exercises the protocol, and asserts the output. A typical run prints something like:

You can also try it interactively. Start the server, open another terminal, and use nc:

We started with the standard MINA pattern — a messageReceived callback containing the whole protocol switch, plus synchronised collections for shared state — and ended up with one ten-line IoHandler whose only job is to forward inbound messages into a channel, plus a single runProtocol method that reads top-to-bottom.

Each Groovy 6 feature earned its place:

Our hub trusts whoever feeds it. Next time, we will wire a fleet of broker boxes to feed the BroadcastChannel`s we built today — using Apache MINA SSHD as a client, parallel collection methods (`collectParallel, eachParallel), Pool.virtual() for the I/O pool, and async file I/O on Path for log capture. The producer side gets all the attention; the consumer side — everything we built in this post — stays unchanged.

Apache MINA’s filter chain and IoHandler model still give us a clean, well-understood place to plug in a network protocol. What changes with Groovy 6 is what we put inside the handler: instead of cramming protocol logic into callbacks and synchronising on shared collections, we let the handler shuttle events into a channel and write the protocol as one straightforward async method. The new toolkit — async/await, channels, broadcast, @ActiveObject, and AsyncScope — composes naturally with MINA, and the result is network code you can read top-to-bottom.