tags:

views:

44

answers:

1

I have a logical publication which is basically a bunch of MT servers, who all access a DB subscription storage. These MTs are typically upgraded by taking 1/2 out of rotation, installing the new MT version, bringing them back online, and then repeating for the other half.

I am confused how a subscriber would subscribes to such a publication. In all of the examples I have seen, a subscriber needs to have a publisher's InputQueue specified in configuration in order for the subscription request to be received. But what InputQueue would I specify in this situation? I don't want subscription to fail if some of my publisher MT's happen to be down. Would I just subscribe manually by adding a record to the DB subscription storage?

A: 

Publishers usually publish as a result of processing some command from a client, and as such, you usually use a distributor to scale them out, as well as using the DB subscription storage. Subscribers are another kind of client so you would configure them to point to the distributor as well.

Udi Dahan
I see, so you can put a distributor in front of the publisher nodes, just to accept the incoming subscription requests. Makes sense! Given my scenario, however, I don't love the idea of treating publishers this way. Basically, I don't like the typical behavior of NServiceBus where the subscriber sends an idempotent "subscribe me" message to the publisher once every time it starts up. I would rather have one install script to deploy a subscriber worker node, and have another for installing the distributor and registering the subscription (by adding a record to the DB). Will this work?
skb
Sure - you can do that. Just add .DoNotAutoSubscribe() after .UnicastBus() in your initialization code.
Udi Dahan