Howdy everyone. We’re currently evaluating NServiceBus using several PoCs in our organisation to see how it fits in for our use on evolving an existing legacy system. As a bunch we’re pretty familiar with messaging systems and have done extensive work on large applications designed with that in mind. We’re pretty happy with our results so far and have to say that from just a year maybe two ago, your documentation and samples have really come a long way. However we do have a few questions about very specific recommendations, generally about IEndpointInstance use and management that we figured we’d reach out and see if we can get some guidance about. These generally cover an area I don’t think is well spelled out in the docs and samples and we’ve not been so far able to find anything current on to say one way or another therefore we come before the synod
For completeness we’re using
NServiceBus 6.0.0
Sql Transport 3.0.0
Castle integration 6.0.0
Callbacks 2.0.1
NHibernate integration 7.1.1
In additional everything is in the same database and it’s pretty plain deployment. In addition we’re not running installers (we precreate queue tables) nor do we handle (for now) subscriptions dynamically but have a management process to enter the configuration; It’s rather straight forward after all.
- Say we have a client application that is used to send a particular set of commands (specifics don’t really matter here). These commands are handled on another application and what they do isn’t, again, particularly important for this conversation. Both commands would be using an identical configuration when it comes to conventions, transport, persistence, etc.
So for simplicity here we have a Comand Foo and Command Bar that do really interesting stuff They are both, logically SendOnly endpoints. We drop a message on the bus and they go off and life is good. So the question here is about the endpoint use on the client app:
Is it a best practice to have a two separate IEndpointInstance basically differing only by name and both otherwise identically configured or is it a better practice to have have one and simply use the differing destination values to send ultimately to the correct location?
Yes we lose some fidelity on the headers but honestly the originating endpoint isn’t really important for us (It may be of importance to the infrastructure or other places where things go sideways when it’s not clear and we’ve just not proverbially ‘stepped in it yet’). I mean, we care it’s from Server X and Application Y, but don’t care to know if the endpoint was sending Foo or Bar commands (i mean the destination tells us that)
In short, should we have a single IEndpointInstance per destination or can we share a single running instance, provided both logical channels are configured the same?
- Let’s do the same scenario now but switch this to a duplex exchange here and best practices for response queues. In our case we’re using at a minimum host and application as an identifying value in this POC. It’s pretty obvious the response instance needs a discriminator so we can get it to the proper place and no big surprise here. The question is then if Foo Command has a FooResult response and Bar Command has a BarResult, can we actually share the same response queue and have Callbacks actually do the correct thing here and even if so, is that even a good idea?
Looking at the exchanges it would appear that everything’s tied together via correlation id and the response queue would just be peeked for the matching value to the request, ignoring the rest. Do they bump heads together or is that a case where they’re fine on the same queue?
note I am not saying use one response queue but two running endpoint instances, we know that ends up with them potentially ditching the response because they don’t think it’s current. One instance handing a dialog for two commands over the same response queue.