Closed LuisGioanni closed 8 years ago
@LuisGioanni I'd assume you already have a small example demonstrating this behavior, could you share it so we have a test case and reproducer to verify the fix?
@pmlopes I just packaged together the 3 projects, you can find them there : https://github.com/LuisGioanni/tcp_eventbus_bridge_issue_reproducer
What it does :
When you call the endpoint localhost:8080/vertx2
it sends a message at the address test
that is registered by Vert.x 2, and Vert.x 2 just replies Hello from vert.x 2
Vert.x 2 receives the message, and the Vert.x 3 emitter never receives the response.
Fixes #11
Version
Context
I have a vert.x 2 project communicating to a vert.x 3 project through the event bus. The vert.x 2 uses the EventBus3 and vert.x 3 uses the tcp eventbus bridge. If the vert.x 3 isn't clustered it works fine, however when deployed in a cluster things go bad. I have a "machine" that just has one Verticle that creates the bridge, and several other machines with my application logic. When I send a message to the EventBus from my app servers, it is caught by the Bridge, sent to vert.x 2, vert.x 2 sends it back to the bridge but the bridge never sends it back to the app original app server.
I looked into the source, and IMO the issue is that when the bridge receives a send event, it then does
eventbus.send(address, ...)
and doesn't consider if it's a response message or not. Locally this works because doingeventbus.send(replyAddress, ...)
is equivalent tomessage.reply(...)
(or very similar in the way it works) but in a clustered environment the behaviour differs and thus doingeventbus.send(replyAddress, ...)
does not work.Ideas to solve this :
Message
in a map(reply_address, original_message) in order to get it back on the reply from the exterior app, and domessage.reply(...)