Hello Hiram!
We need to think of a better approach. Off the top of my head, we
could... :
1) only forward the first subscription, but always strip off any
selector. That way message to the topic are always properly
replicated. The down side: if that in a big network this kills your
scaleability since every broker has to process every message. Might
not be a problem if you have consumers on every node that need to see
every message (but this is typically not the case).
2) if a subscription has a selector, then send a copy per
subscription but somehow target a specific consumer on the remote
broker so that the remote broker does not broadcast the message again
to all it subscribers. Implementing this might be a bit trickier but
should preseve scalability of a broker network.
Any other ideas?
Well, what about delivering an event only once per connection?
If the dispatching process for an event kept a list of connections the
event was already delivered to, it would be possible to prevent
delivering it over the same connection a second time. The event would
reach the remote broker only once, even if there were more than one
matching conduit subscription. And the remote broker would dispatch it
to any matching local subscription. That approach would maintain the
scalability of the network, but I don't know how much it would spoil the
efficiency of the dispatching process.
Best regards
Linda
