SQL Transport Queue Names

[Phil Sandler]

So we're doing some prototyping with NSB using SQL Server as a transport and for persistence (the latter is probably irrelevant).  Version numbers are below.

I'm having a bit of difficulty understanding the queue names that are created and the reasoning behind them.  Currently we are only running these projects locally via Visual Studio.

I have a host process that uses the NSB Host and a web application.  Both projects publish and receive messages (different messages).

The host process creates queues as follows:

MyHost

MyHost.Retries

MyHost.Timeouts

MyHost.TimeoutDispatcher

The web application creates these queues:

MyWeb.MACHINENAME

MyWeb.Retries

MyWeb.Timeouts

MyWeb.TimeoutDispatcher

Why does one use MACHINENAME as part of the queue name, and the other omits it?  Also, why do the retry/timeout queues NOT include the machine name?

I can post additional info about the configs if needed.

Thanks,

Phil

Product name: NServiceBus

Version: 4.4.2

Product name: NServiceBus.SqlServer

Version: 1.2.1

[John Simons]

Hi Phil,

Here is the link for the reason - https://github.com/Particular/NServiceBus.SqlServer/issues/2#issuecomment-24493875

Cheers

John

[Phil Sandler]

John,

The reason appears to be "to support callbacks by default".  Can you explain this in greater detail?  I don't really understand what it means.  It also says that it's correct that the machine name is only on the main queue, but doesn't explain why.  And it says it overrides this behavior on AsA_Server, but  (again) doesn't explain why.

Does this naming imply some sort of limitation, either on the host side or the web side?  Are certain scenarios not supported using SQL as a transport?

Thanks,

Phil

[Jimmy Bogard]

Callbacks being

Bus.Send().Register(/* callback here */)

Correlated request/reply (I believe).

--
You received this message because you are subscribed to the Google Groups "Particular Software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to particularsoftw...@googlegroups.com.
To post to this group, send email to particula...@googlegroups.com.
Visit this group at http://groups.google.com/group/particularsoftware.

To view this discussion on the web visit https://groups.google.com/d/msgid/particularsoftware/dbc4a217-92cb-46eb-8d88-36cb304aa7b4%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Phil Sandler]

I guess my question is more around *why*.  Why does the queue name require the machine name for endpoints other than AsA_Server to support callbacks by default?  Why don't the additional queues also require this naming?  Plus I'd like to understand what the implications of this are, and whether certain scenarios are not supported.

[John Simons]

Hi Phil,

Sorry that the link I sent you did not provide all the answers.

To explain it I need to go into technical details so bare with me :)

The reason why is because NServiceBus callbacks are correlated using an in-memory dictionary that keeps track of messages ids going out and messages ids coming in, so in other words when you do Bus.Send().Register(/* callback here */) in your web site we add an item to this in-memory dictionary saying that we sent out a message with id x and we also store the callback delegate and then when we receive messages we check that dictionary and if the correlation message id matches we fire the callback delegate.

So this means that if you scale out your web site (eg a web farm) where you deploy the same endpoint to multiple machines if the primary queue name for these endpoints were named the same any of these scaled out endpoints could pick up messages that are suppose to go to a specific endpoint/machine, which then would fail because the callback message would not exit in the in-memory dictionary for that endpoint/machine.

I hope this technical explanation makes sense ?

>Why don't the additional queues also require this naming?

Because the other queues do not receive callback messages hence do not require the originator endpoint/machine to be the receiver.

>Why does the queue name require the machine name for endpoints other than AsA_Server to support callbacks by default?

Because the callback feature is suppose to be only used from a AsA_Client endpoint.

AsA_Server endpoints are suppose to use normal Send/Reply

>Plus I'd like to understand what the implications of this are, and whether certain scenarios are not supported.

Hopefully my explanation at the beginning answers this question too?

Cheers

John

[Phil Sandler]

Yes, this makes perfect sense.  I appreciate the detailed explanation!

Thanks John and Jimmy for your responses.

Phil

[Meyc]

NSB, v5

Is there a reason that this is different with Azure Service Bus?  I am getting {endpointName}-{machineName} for the queue, retries, audit, error, and the topic created for events.  So if the endpoint name is "Endpoint1" and the machine is "Machine1" I am getting 

Queues

endpoint1-machine1

endpoint1-machine1.retries

endpoint1-machine1.error

endpoint1-machine1.audit

Topic

endpoint1-machine1.events

I can see the main queue including the machine name for the scenario similar to the explanation above.  I am not sure why the machine name is being included for error, as the general guidance is to use a single error queue.  I assume the same may hold up for audit.  Also, I know that publishing events from a web application is generally discouraged, but having multiple event topics for events makes the subscription side more difficult because you are ending up with the same message types under different endpoints.  I don't think it is possible to set up a subscriber of multiple endpoints that are publishing the same message type.

[Sean Feldman]

Meyc,

Are you running on premises with Azure Service Bus transport?

[Sean Feldman]

Meyc,

If you're using queue per endpoint ( config.ScaleOut().UseUniqueBrokerQueuePerMachine(); ), you'll have that.

Defualt is to use is to a single single broker queue ( config.ScaleOut().UseSingleBrokerQueue(); )