Extensible invocation of TcpClient in ReactorNettyTcpClient

[rupebac]

We would like to achieve something as basic as sending all Stomp sessions from a specific user to one Stomp relay, while other users may go to other Stomp relays. This should minimize I believe the traffic inside the Artemis cluster.

I know I can use TcpClient#remoteAddress(Supplier...) but this is not enough for what we try to achieve. We need to know the context of the incoming connection to know to which remoteAddr send that to. I mean, we need to gather the session id / user principals of the incoming session, to decide to which relay it should send that Connect request to.

I know I could extend ReactorNettyTcpClient and Override connect(TcpConnectionHandler) but then I need to reimplement myself the whole ReactorNettyHandler (as this one is private).

Ideally ReactorNettyTcpClient should internally allow some sort of tcpClient resolver, or at least it should, I think, use a getter for the TcpClient (so that I can override the getter myself).

Is this possible at all with the current code base? What would be then the correct way to achieve this?

[rstoyanchev]

If you override ReactorNettyTcpClient#connect you still don't have access to session or user id. That's pretty low level with no knowledge of the context in which the client is used. Come to think of it I'm not entirely sure what the context here is? Is it in the context of the StompBrokerRelayMessageHandler, where we could add a protected method to obtain the client to use also passing in the StompAccessor, or in the context of ReactorNettyTcpStompClient?

Also could clarify how this would minimize traffic inside the cluster?

[rupebac]

You mean, a protected method in StompBrokerRelayMessageHandler called by StompConnectionHandler#connect? That would work out yes. Also centralizing the access to the tcpClient in ReactorNettyTcpClient from both #connect methods in a protected getter would also make it.
Additionally, I have opened a PR, to populate the sessionId in the TcpClient attributes. Leaving more room for more customizations there in the future.
I guess the main problem is that all this code was thought on times where TcpClient did not have any lazy evaluation of the remote address, and you can still see the StompBrokerRelayMessageHandler#getRelayHost which does not make much of a sense with a lazy evaluation of the remoteAddress via TcpClient.