Reputation: 82351
My model has me getting data from a TCP connection and then sending a command to an NServiceBus "Hub" service. (That Hub will publish the data to all subscribers.)
The TCP connection needs an ACK (acknowledgment) that I got the message (or it will re-send it). Before I ACK the TCP message, I would like to know that NServiceBus has safely sent the message on its way (and if the delay is not too long, I would also like to know that it got to the other end (the Hub Service)).
Is there any kind of ACK system built into NServiceBus? Or do I just trust that the message will be successfully sent?
Upvotes: 0
Views: 662
Reputation: 1577
You can manually add a central database (accessible from both clients) and maintain the status of the messages. Say like if u send message from one client, just add a row in the central database. Then on receiving the message at second client, update that row to acknowledge that the message has been received.
Upvotes: 1
Reputation: 31760
If you use transactional NServiceBus you can pretty much know that the message will be successfully delivered. This is the case even if the hub service is offline, as the messages will queue up in a durable fashion waiting to be delivered.
For this reason, waiting some kind of ACK from the service can actually be counterproductive and can needlessly interupt processing.
However, in answer to your question, I am not aware of any built in functionality which does this (Udi Dahan may be along later to correct me), though this would involve another message being sent back to the caller.
This ack message would need some means of being tied to the request message which was sent originally, some kind of token or ID which would allow the ack to be matched against the original call.
Hope this helps.
Upvotes: 0