vertx-eventbus-bridge-clients
vertx-eventbus-bridge-clients copied to clipboard
vert-x3
Transport reinitialization
Right now, the Transport (netty Channel) is only being constructed in the EventBusClient factory methods (tcp and websocket). Yet, in the life of an EventBusClient instance, it may be necessary to re-construct a Channel (e.g., the xxxProxyHandler is being removed for performance reasons after successful connect).
This depends on the actual Transport implementation, e.g. a WebSocketTransport channel might be closed by the server if a message larger than maxWebsocketFrameSize was send to the server.
A xhr-polling or xhr-streaming protocol additionally might have the requirement to have multiple channels open simultaneously or in series. On the other hand, it's ping command might be different (my current understanding is, that the server issues a heartbeat-frame every now and then instead of the client sending a message of type ping).
What do you think about creating an intermediate layer between EventBusClient and Transport to handle those differences? I would PR soon. ;-)
Implemented in https://github.com/philrykoff/vertx-eventbus-bridge-clients/tree/java-client-next - will be PRed next.
Hello @vietj in case this is still needed for outreachy, i will be gladly to work on it, Am sharif magembe happy joining and participating as outreachy intern.
