Posts by brian

    Thanks, that's very helpful. If I understood correctly, it sounds like a hub consisting of 2 brokers would act very similar to just bridging 2 brokers with a parentId.

    For a simple deployment of just 2 or 3 brokers, would there be any reason to introduce a hub? Is that more of an advanced configuration, once you start to scale out to many brokers across different sites and you want the resilience between hubs?

    I've configured 2 brokers according to the documentation on Bridging and observed that:

    • events are bi-directional between the brokers (e.g. you'll see events regardless of which broker you send them to or which broker you subscribe to an event)
    • a service registered on broker1 can be accessed from a client on broker2 and vice versa
    • a service can be registered to broker1 and broker2 and clients connected to broker1 and broker2 will have their requests handled by the closest service
    • if one of the services fails, clients can still access the service on the other broker, regardless of which broker they are connected to

    This appears to be a good design for an Active-Active configuration for high availability.

    Hubs are only referenced in the doc for the brokerstate.policy and it's not clear what benefits they provide and they do not appear to be endpoints for clients. The doc on Bridging does not use them and the fields for "primaryBroker" and "secondaryBroker" are not documented.

    Can you explain how they could or should be used and their impact on an Active-Active configuration?

    Based strictly on Bridging, it would seem a simple setup with 2 servers, each one having a broker instance and possibly multiple service instances connected to each broker, would provide fail-over and load-balancing across the services.