What if you have you have a single consumer that lives outside the brokers and that connects to one broker in the mesh and gets all advisories (from all brokers) from that one broker? There are no selectors involved, no composite destinations, and no duplication, and the only downsides are 1) you need another host on which to run this, which will stay up even if one of the brokers goes down, and 2) to survive outages of some of the brokers, you'd need to construct a failover URI containing all of the brokers in the mesh. But neither of those downsides seem worse than the disadvantages of the other things you're trying.
Tim On Tue, Aug 29, 2017 at 11:00 AM, Raffi <raffi.onj...@gmail.com> wrote: > We have a broker network of 12 brokers in a complete graph, so every broker > has a separate connection to every other broker. We want to consume and > forward some advisories messages from each broker to splunk; the splunk > integration is not important, our concern is the subscriber itself. Our > current approach uses an embedded topic subscriber which starts and stops > with each broker; since advisories are only emitted during the life of the > broker, this solution made the most sense. But when the topic subscriber > starts, it receives advisory messages for all brokers, not just the locally > connected broker, not what we want. > > The next approach we tried was using composite topics; forward all relevant > advisories from the local broker to a designated queue; we figured the > broker ID was sufficient for uniqueness to ensure the local consumer was > the > only one consuming from the queue: > > <compositeTopic name="ActiveMQ.Advisory.Queue" forwardOnly="false"> > <forwardTo> > <queue physicalName="Advisory.mybrokerID.toSplunk" /> > </forwardTo> > <compositeTopic> > > This solution has one very big downside; composite topic names (the source > topic, not the target queue) don't appear to support wildcards; since many > advisory topics are suffixed with the destination name on which they advise > (ex: "ActiveMQ.Advisory.Queue.topics.mytopic"), static configuration can't > keep pace with dynamically changing destinations. > > Next, we went back to our original solution, embedded topic subscriber, but > this time the subscriber uses selectors to filter advisories based on > broker > ID from which the advisory message originated; thankfully there's a header > for that. This worked, but we have concerns regarding overhead since > selectors are server-side, moreover, we haven't enabled selectors for > network connectors, as such, this approach creates a lot of unnecessary > network chatter unless we enable network connector selectors. > > ..and now we're out of ideas :-) > > Are we missing other potential solutions? > > > > -- > View this message in context: http://activemq.2283324.n4. > nabble.com/Possible-to-create-broker-specific-topic- > subscriber-in-broker-network-tp4730057.html > Sent from the ActiveMQ - User mailing list archive at Nabble.com. >
