-
Notifications
You must be signed in to change notification settings - Fork 37.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
BrokerAvailabilityEvent without any relay node information? #25890
Comments
I am wondering have you considered using |
Thank you very much, yes, I ended up doing what you are saying. However it is not as simple as that, since doOnDisconnected is also triggered when the user closes the session gently by sending DISCONNECT. I have managed to work around by adding an OutboundAdapter that listens on "close" (which is triggered when forwarding a DISCONNECT), and adding an InboundAdapter that listens on channelInactive. In all my tests this is working as a charm. Why can't you do that and trigger BrokerAvailabilityEvent from there? If you are open for a PR, I can submit. This simple thing took me quite a bit of time to achieve, and it woud be great if BrokerAvailabilityEvent is not only bound and triggered from the system session, but also when the user session is being closed unexpectedly from the broker side right? |
Again I don't see any way for the broker to obtain this information. It's just working with |
Why are you not triggering the event here for example: Line 469 in 702a05e
? If you only trigger it from the system session, then I guess it is relatively easy to know to which server the system session is connected (specially if you would approve my other PR in #25889). |
There is no need to trigger the event there as well. That's for messages specifically to the system session which already detects publishes the events.
Only if you use the relayHost and relayPort properties but in that case there isn't much to guess. If you configure TcpClient directly, the |
I know this is triggered from Also the solution you gave for me other issue #25889 is helping me to find out where the system session is connected, and this is not necessary anymore as long as you are only triggering this event from Due to all this, I close this issue. Feel free to contact me for further help/review. Thanks a lot |
Scenario: I am connecting to a cluster of Stomp relays (without external LB), one of the Stomp nodes goes offline and I therefore receive the right
BrokerAvailabilityEvent
, but from this, I can't see how to grab the specificTcpConnectionHandler
instance that triggered the event. I mean, it is hidden. Without that, how am I supposed to know which node exactly went offline? My intention was to leave this node out of the candidates pool for some time (5min or so) before consider putting him back to make him a candidate on thetcpClient#remoteAddress()
.The whole thing I think is misconceived, it seems to be taking the relay port just from the
StompBrokerRelayRegistration
, without considering it may be chosen dynamically by theTcpClient layer
underneath.Am I missing something?
The text was updated successfully, but these errors were encountered: