Pub/Sub Issues

Feb 17, 2009 at 5:09 PM
I'm trying out the pub/sub features and think there may be a problem.  I haven't pinned it down yet, but I thought I'd raise it in case anyone else has come across the same problem.

It seems that when you have two subscribers to the same data, sometimes one fails to register, and so only one gets the messages.  It seems OK if you start up the publisher, then the two subscribers slowly, but I haven't done enough tests to confirm the exact conditions.
Feb 17, 2009 at 7:06 PM
Are you using the latest version from the repository?
Feb 18, 2009 at 8:25 AM

Yes - 5.5.  I'm going to try and trace thru the code to see what's happening today.

Another thing - It looks like subscriptions aren't persistant. i.e. if the publisher is shut down and then re-started it doesn't remember what it's previous subscriptions were.

Feb 18, 2009 at 3:51 PM
Please let me know if you find anything re the subscriptions. As for subscription persistence, you're correct, they included subscription manager is not persistent, it is just a in memory hash table. You will probably want to implement a database subscription manager that fits your environment. We will probably be adding an NHibernate/ActiveRecord subscription manager in the near future, but no firm timing on that.
Feb 22, 2009 at 5:53 PM
I think I fixed the subscription problem, there was a threading problem in the subscription manager due to my trying to be too fancy with a reader-write lock. I put everything into a writer lock and it seems to have resolved the problem. Of cou
Feb 23, 2009 at 12:33 AM
The default subscription manager is now persistent - the NullSubscriptionRepository has been replaced by an XML Flat file repository.
Jul 8, 2010 at 3:15 PM

Is this still the case where by default, subscriptions are now persisted to xml flat files?

Jul 8, 2010 at 6:34 PM

this is the case if you rely on the Publish method of the message bus, which I don't use with the ActiveMQ transport. In the latter case, I make no difference between a send and a publish, as this is only a configuration issue for the message's destination which can be either a queue (Send) or a topic (publish). A developer should only care how to send a message but not where to send it.


Jul 8, 2010 at 9:01 PM

I completely agree with that statement. In fact, the sender of a message shouldnt care if its destined for a single consumer or multiple consumers. 

Just so I'm clear, though....just by using and configuring the SSB ActiveMQ adapter, developers creating message handlers do not need to worry about subscription persistence? Or are you doing something different in your subscription and publish/send logic?

Jul 8, 2010 at 9:55 PM

Nope. But if their handler consumes a message routed through a topic, they have to choose if they really care about the message or not.

If they don't, they can simply subscribe to the topic which means that when the endpoint is offline and then resumes, they won't receive the topics sent while the endpoint was offline.

So, if they do care, they have to subscribe to the topic and specify a durable name, which means that ActiveMQ will keep a copy and dispatch it the next time the endpoint becomes online and uses the same durable name.

Note also, that when you create a ConsumerPool and you mix queues and topics, the pool will automatically switch to a single worker thread, as otherwise you would receive the topics in each worker, which would duplicate the notifications!

Jul 9, 2010 at 2:21 AM

Makes sense. I can live with that. Coming from a JMS background, it seems a natural adaptation.