Add asynchronous MessageHandler interface

[matthewadams]

Feature Request

The current MessageHandler interface has a synchronous method. Please provide an asynchronous version of the same interface.

Use Case:

Not sure, but hoping that providing this would allow more messages to be handled at a given time.

Proposed Change:

public interface AsyncMessageHandler {
    CompletableFuture<Void> onMessage(Message msg);
}

along with concomitant changes, like adding a method to Connection like AsyncDispatcher createAsyncDispatcher(AsyncMessageHandler handler).

Who Benefits From The Change(s)?

Those writing MessageHandlers that invoke asynchronous methods, specifically, Kotlin suspend functions, as well as future use by Java fibers (Project Loom).

Alternative Approaches

?

[scottf]

I'm happy to discuss this with the clients development teams, but you can certainly accomplish this yourself, by having your synchronous message handler distribute the messages asynchronously.

[liangyuanpeng]

Vertx for nats may help : https://github.com/nats-io/nats-java-vertx-client

[scottf]

Vertx for nats may help : https://github.com/nats-io/nats-java-vertx-client

It won't. That vertx client is a wrapper around the existing client. It's on the roadmap to replace the connection layer in the current client with actual vertx

[matthewadams]

As long as I can use the Java client from Kotlin with suspend funs, I'm ok, but I'd rather see y'all either rewrite the Java client in Kotlin, or provide a native Kotlin client.

Is it on the roadmap to support Java fibers/virtual threads/Project Loom?

[mzazaipsc]

Vertx for nats may help : https://github.com/nats-io/nats-java-vertx-client

It won't. That vertx client is a wrapper around the existing client. It's on the roadmap to replace the connection layer in the current client with actual vertx

"current client" means Java client or Vert.x client? Would be super exciting if the Java client would use Vert.x, and would love to contribute to it if that was to be considered.

[scottf]

1. Virtual Threads are supported in Options for the dispatcher / internal tasks. For instance:

new Options.Builder()
...
.executor(Executors.newVirtualThreadPerTaskExecutor())
...
.build();

We've also really cleanup up interrupt handling throughout the entire client.

2. You could make an async message handler. Take a look at NatsDispatcherWithExecutor which can be used with an Options:

useDispatcherWithExecutor()

In this mode, every single message is dispatched via a task, using whatever executor is provided (1), instead of a direct call. Theoretically I suppose it's possible to get a message out of order, but I've only made this available, not really tested or used it.

3. The Vertx client wrapper is in use by a customer with much success. It has a custom dispatcher and uses the vertx event loop, there was a whole change to the client to support providing the dispatcher. KV is also currently supported.
There is not a whole lot of code, but it works and the customer seems to be happy with it. Not perfect, but a bridge.

4. There is no timeline for vertx support directly in the client. We are definitely considering it.