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?