Add callback-based method in Channel

[acogoluegnes]

E.g. in Channel:

void asyncRpc(Method method, CommandCallback callback) throws IOException;

With:

public interface CommandCallback {
	void handle(Command response);
}

This could allow to build a reactive API and also, combined with NIO, to have a truly non-blocking client (right now RPC calls are serialized, at least at the channel level).

[michaelklishin]

I suspect we then want an entire new ChannelN implementation.

[michaelklishin]

…and perhaps an interface, e.g. AsyncChannel. I'd also consider using futures over callbacks (or at least both).

[acogoluegnes]

We may not have to rewrite ChannelN from scratch, I hope we can change the outstanding RPC call property in favor of a queue and support the callback scenario.
The point here is to have a foundation for reactive and opinionated extensions to build on (they tend to prefer callback over futures usually).
The AsyncChannel scenario would be something else, more involving I guess.
I'll try to start experimenting in the next days/weeks.

[smaldini]

Yes please no Future or it would be CompletableFuture if the java version supports it. Even so, the problem is more that we need to have the basic abilities to :

• trigger async work on demand (call method), ultimately we will have to bridge in a reactive API with a deferring operation to trigger the call on subscribe only.
• not blocking on that async method at all, Future#get would only encourage that, kafka mixed up these two API styles.
• getting the status in the callback : success(result)/error(cause) or getting 2 callbacks for success/error
• resulting only when operation is complete for single result or n times for n results on stream of callbacks (channel consuming) with close/error callback to be provided
• inspired from https://github.com/reactive-streams/reactive-streams-jvm even tho its not implementing it. For instance success/error should be unique and terminal, definition of "blocking operations" and effort to keep it efficient.

[michaelklishin]

I have no problem with rolling with CompletableFuture and requiring JDK 8 now that we are no longer tied to RabbitMQ releases and thus can bump version numbers at will.