What are some strategies for detecting when other processes are listening to a queue or topic?

I have a system (let's call it System A) that allows the user to turn on certain processing functions. When these functions are activated, System A will listen for messages from System B.

System B currently sends these messages out to the topic at all times, regardless of whether System A i开发者_C百科s listening. These messages aren't horribly expensive to generate and send, but nonetheless I would like to avoid sending them if System A is not listening. (Note that these messages do not need to be durable, System A can start/stop listening at any point and function correctly.)

I am using ActiveMQ as the message broker.

I can see a few possible solutions to this.

1. Create a registration/subscription message that System A would send to System B. I'm not quite sure how often this message would be sent, or what kind of state would need to be persisted by either side.

2. Rely on ActiveMQ advisory messages to detect when there are no listeners.

3. Tune ActiveMQ to be as efficient as possible when sending messages to a queue with no listeners (still probably requires generating the messages).

I like the idea of #1 best, but I'm having trouble seeing how that comes together without dramatically increasing complexity.

Personally, we've taken the approach of dropping the message onto the topic. Especially if it is a non-durable topic, ActiveMQ is efficient at sending with no listeners. Plus, one big benefit of using the messaging middleware is the fact that publisher and subscribers don't have to know about each other or maintain state.

However, if the business drivers are such that you still want System A to know about consumers, there is a JMX call that is available to see the number of consumers on a queue or topic. Assuming that System A can make jmx calls, you can query the ConsumerCount attribute on the MBean Object org.apache.activemq:BrokerName=localhost,Type=Topic,Destination= (substitute your own BrokerName and topic name) at some regular interval, and if the count is > 0, then construct and drop messages onto the topic.

I would recommend that approach as it puts all of the state management on ActiveMQ, and System A doesn't have to manage any state.

Advisory messages can give you this sort of info, or you could also you the BrokerStatisticsPlugin that's available in AMQ, it allows your client to send a message and have the broker send you all sorts of nice information about its current state. It also has the benefit of being a bit easier to use than JMX.

See: http://activemq.apache.org/statisticsplugin.html

If you want a truly broker agnostic solution that you'd probably have to go with you option #1 since the others rely on features specific to AMQ.

Regards

Tim www.fusesource.com