When the service goes to respond to the GetAllUsersMessage it can do so in a transaction that prevents other updates from occurring concurrently. It responds with a list of UserAddedMessages. All the updates that were blocked now continue, arriving at the new server.

Regardless, you can choose how long these messages are kept around by defining a [TimeToBeReceived] on them.

I skimmed the code trying to understand how the cache is brought to consistency. If I have a web farm and a reboot or add a new webserver, I see in the code that it would subscribe to the UserAddedMessage then send a GetAllUsersMessage(). In the meantime new users are being an asyn’d back to the main service to for storage (the one responsible for responding to GetAllUsersMessage()), and the other webservers are keeping their caches consistent. So what about the messages I seemingly didn’t receive? The gap if you will. When I subscribe I does the nServiceBus give me all messages in the queue for the day that haven’t been flushed or timed out in some way? Thus I get replayed to me some redudant UserAddedMessages? (but who cares). I guess I am a little confused on how long UserAddedMessages are kept around and how it is know that a subscriber has received them.

Glad you liked it.

There are currently 4 samples for using nServiceBus which are accessible via subversion on the sourceforge site. That would be the most up-to-date version. You could also just use the download link (currently version 1.6.1), and find the samples there.

Three of the samples are under the “samples” directory:

AsyncPages – which shows how to integrate nServiceBus with ASP.NET 2.0’s asynchronous programming model.

Full Duplex – which shows how to do client/server correlated request/response.

WebServicesBridge – which shows how to expose synchronous web services on top of nServiceBus.

The fourth sample is the most comprehensive and is under the “test” directory. It is currently in the process of being documented better.