Can I use more than one broker relay, with something else than STOMP?

[knockoutuser]

From what I see from the application and the Spring code, seems you can only register one broker relay, and it must be a STOMP broker relay.

Can I register more than one? Must I always use STOMP?

[rstoyanchev]

The internal processing is intentionally not tied to STOMP 100% and is intended to be able to support other STOMP-like protocol, hence the "simp" package which stands for simple messaging protocols. If you look at the SimpleBrokerMessageHandler for example it works entirely with SimpMessageType and SimpMessageHeaderAccessor. Of course support for any additional protocol must be added -- the one piece required at a minimum is a SubProtocolHandler, and then the Simple Broker or the equivalent of StompSubProtocolHandler.

What do you have in mind?

[knockoutuser]

I understand the processing is not tied to STOMP 100%, but is it 0%? What I mean is this: is it just a matter of swapping one implementation with another or is the framework tied in some way of STOMP? Just one example to see where I'm coming from, when configuring message broker options it's registry.enableStompBrokerRelay not registry.enableBrokerRelay.

I like STOMP because of it's familiarity (from HTTP) but I can't ignore it's verbosity. If you are pushing lot's of information from the broker, very fast, you end up with a lot of bandwidth consumed by meta information instead of actual content (the headers taking up more space than the body). A custom protocol (maybe with some operation codes instead of headers) might be more lightweight, or maybe you have already an infrastructure set up and you are using AMQP everywhere and don't want to throw another protocol in the mix just because that's the supported protocol at the moment.

As for having more than one broker relay I'm thinking of something like "poor man's load balancing" for example with a simple mechanism in the web app of choosing between broker nodes instead of having another load balancer equipment/application in front of a clustered message broker. This scenario is a bit contrived, I know, but that's the general idea I have in mind.

[rstoyanchev]

I realize the 100% comment was a bit unclear. What I meant is that it is not tied to STOMP to the extent that it should be possible to plug other similar, simple messaging protocols -- e.g. MQTT and WAMP. If you look at SimpMessageType you'll find the basic message types listed there are present in all those protocols and it should be possible to support them alongside by mimicking what we already for STOMP. MQTT in particular is meant to be quite minimal so it might be of interest to you. The simple broker and annotated methods for example should still work without any changes.

Just one example to see where I'm coming from, when configuring message broker options it's registry.enableStompBrokerRelay not registry.enableBrokerRelay.

This is out-of-the-box configuration we provide. It probably could be extended a little bit to support a custom broker (unknown to the framework). That shouldn't be hard to do and in any case you can always extend AbstractMessageBrokerConfiguration or bypass the provided default configuration setup entirely.

Regarding AMQP that falls in a different category of messaging protocols. I am not sure exposing it directly to browsers is ideal and at any rate you'll need a browser-side library to do that.

I'm not sure I followed the comments on load balancing since I'm not familiar with your setup in the first place (e.g. simple broker vs broker relay, etc).

[knockoutuser]

Thank you for the details, it's clearer now. As for the comment on load balancer I'll try to explain further. I can't add complete details since this is just an idea I'm playing with at the moment and hasn't taken full shape in my mind, but it goes something like this:

Assume I have a message broker with N clustered nodes, each node with its own IP address. If I do a registry.enableStompBrokerRelay I need to set a relay host and port so I see two options here:

1. set the host:port of one of the nodes. If the broker node fails my application basically stops and all clients are disconnected. They have nowhere to reconnect and have to wait for the broker to come back online.
2. have the nodes behind a load balancer that exposes only one IP for all the nodes. The load balancer gives me a node and my clients connect to that. If the node fails I can reconnect and the load balancer will give me another node from the cluster, and so on.

What I had in mind was a variation of number 2) but without the load balancer, i.e. have the web application connect to a node and do a load balancing once that fails. For example listen to the BrokerAvailabilityEvent and when that notifies me of a down node have the application go for another node.

There is this nice property on the Spring AMQP connection factory that does something similar when retrieving a connection: setAddresses. It retains a list of addresses and tries to get a connection from the first one. If that fails goes for the second, and so own. I was thinking something in that direction: have two broker relays in the web app, monitor them with the BrokerAvailabilityEvent and direct clients to one or another and if one fails then send them to the other and so on. Do you thing something like this is possible? Any advice?

[rstoyanchev]

hi, just curious, if the broker is becoming unavailable frequently? If the assumption that the broker and the application are on the same network, then it should fairly stable.

The StompBrokerRelayMessageHandler has a reconnect strategy. It does this in startInternal:

this.tcpClient.connect(handler, new FixedIntervalReconnectStrategy(5000));

While the interface ReconnectStrategy is very simple the underlying reactor.net.Reconnect allows specifying a different IP address on each retry. So we could make our own ReconnectStrategy a little smarter and expose it for configuration. So then you can plug your own logic for reconnecting to brokers.

We could also make the default reconnect strategy then a little smarter by allowing a list of hosts and ip addresses to be configured and then trying them in some order..

[knockoutuser]

Interesting, I'll give it a try and see how that works. Thanks a lot!

[GADNT]

Hi @rstoyanchev

Related to your last comment. Do you know that the approach you mentioned have been implemented?
If yes or do you know , can you point to me an example that take this approach with having more than one broker available ?

Thank you
Gabriel

[rstoyanchev]

Unfortunately no, see here and also here.