Default error queue address to "error"

[timbussmann]

Currently, users have to configure an error queue in order for an endpoint to startup correctly. If no error queue is configured, NServiceBus throws an exception on start.

This has a huge impact on the first time experience since they will almost certainly run into this exception as there is currently no way to ensure the existence of that configuration value at compile time. Also, for most first time users, configuring an error queue is most probably to complex and uninteresting when just playing around with NSB.

I think we should configure a default error queue name (to define, "error"?) instead of forcing users to create one.

[SimonCropp]

-1 defaulting queue names means people are not made aware of a decision they should make very early on

[andreasohlund]

We can have the Development transport default it to "error" as a middle ground?

[SimonCropp]

ahh the mythical "Development transport"

[andreasohlund]

it's just one failing test away from me removing the [WIP] :)

[timbussmann]

-1 defaulting queue names means people are not made aware of a decision they should make very early on

@SimonCropp According to our vision/strategy, First Time Experience is one of the most important aspects. I'm not sure if I agree that users should mind about the location of their error queue very early on? It's a configuration value, means you can basically change it any time, why is it required early on?

[andreasohlund]

The development storage could default to "error" making it just work for first time users.

We could also let each transport default since for all transports other than MSMQ "error" is just fine

[tmasternak]

First time users experience is not a main goal of the V6 release. This can be tackled as part of that initiative when we start it.

/cc: @boblangley @danielmarbach

[SimonCropp]

i would prefer @colin-higgins endpoint generation site to be the thing that removes the friction of the first time user experience. that and the bootstrapping nuget. not compromising API (used in the long term) on the alter of initial user experience (only valuable in the short term)

[danielmarbach]

@SimonCropp What would be the drawback of having a default error queue name set to 'error' queue? I tried to reflect about your statement #3647 (comment) and figured it matters only when we assume a centralized error queue. Unfortunately when I skimmed through the doco page I could not find clear guidance why you'd want to have a centralized error queue. Under that light setting a default error queue would not be harmful, right?

For all non-store and forward transports a default error queue name with "error" would be a good fit more a large portion of our user base.

[timbussmann]

-1 defaulting queue names means people are not made aware of a decision they should make very early on

@SimonCropp I'm not really sure how "aware" we make users by forcing them to configure a string. There is no further information about a "decision they should make" by that API.

regarding @andreasohlund idea about the dev transport: That essentially means, error queue configuration would become a transport responsibility. This could make sense since broker based transports require less "decisions" to make (just the name of the queue in almost all cases) compared to msmq.

[SeanFeldman]

I might be off, so please correct me if I'm wrong.
When dealing with system queues (that's what we ended up calling them with @andreasohlund), it was assumed that in the next major/s we'll not create any of those. Those queues should be created by the users. Is that something that should be considered for this discussion?

[timbussmann]

@SeanFeldman I think for that there are more changes required until we completely skip queue creation (e.g. the "development transport").

[dbelcham]

Talking to @timbussmann and we came up with the following thoughts/ideas:

The current experience for a new (or any) user when creating a new endpoint is one that sees them think that they have done what is necessary to create an operating endpoint only to have it error on them during the first run. There is no feedback prior to endpoint startup that outlines what may be missing. The API by itself doesn't provide any context about why an error queue is required to have an operational endpoint. When a user is trying to start their first endpoint with NServiceBus understanding the reasons why an error queue is required is not necessarily their primary concern. They will have it as a concern at some point, but not during the first attempt to run their endpoint. Because of this, having a default error queue value configured would make that part of the experience have less friction from an operational standpoint and a conceptual one.

• the only scenario where a default error queue name would not be a reasonable choice is when using MSMQ + centralized error queue + Service Control
• all other transports could use a default error queue name without issues
• it seems to make sense that the transport would define any default error queue name. Nobody knows better what could be valid (i.e. valid naming conventions, characters, ect) for a transport than the transport itself
• if default queue naming is delegated to the transport, MSMQ could decide that it doesn't want to use a default value and instead require explicit error queue names to be provided during endpoint configuration

Does anyone else see any downsides from using a default error queue in the manner explained above?

ping @Particular/nservicebus-maintainers @SimonCropp @SeanFeldman

[SeanFeldman]

A new developer is going through an exploratory development. If they learn early on that an error queue is required and the reason why it's required, then we've accomplished 2 things

1. Taught developer about error queue API
2. Seeded the idea of failing messages and potential need to address those

Current exception message looks like the following (with a minor spelling issue, PR created):

Faults forwarding requires an error queue to be specified.
Take on of the following actions:

• set the error queue at configuration time using 'EndpointConfiguration.SendFailedMessagesTo()'
• add a 'MessageForwardingInCaseOfFaultConfig' section to the app.config
• configure a global error queue in the registry using the powershell command: Set-NServiceBusLocalMachineSettings -ErrorQueue {address of error queue}"

While I agree that it's inconvenient to run into an exception for a missing API call to define an error queue, I do think (with perhaps an improved error message) this is the right approach.

[dbelcham]

@Particular/nservicebus-maintainers do we want to move on this in anyway or has the discussion run it's course and no action will be taken?

[danielmarbach]

I'm torn to be honest. From one perspective I don't like the F5, boom exception approach but on the other hand it serves an educational purpose like @SeanFeldman described. I'd say let's close it for now, not important enough

[SeanFeldman]

Before the issue is closed, wanted to bring Evaluate MSBuild integrated installers issue raised by @SimonCropp.

I have a weird feeling of a déjà vu. We tend to change our minds on core things (pun intended) more often than we should. We talk about "system queues" when it's important to drive a discussion towards a standardized design, just to say "it's not important enough" later.

[andreasohlund]

I don't like the F5, boom exception approach but on the other hand it serves an educational purpose

Not convinced that the educational value is high enough to warrant this friction, for all transports other than MSMQ error is just fine for production use. For msmq you would have to change yes but it would not be message loss.

If we had the development transport we would have it default to error I guess?

How about we have each transport set a default if possible and only throw if there is none? (Ie we would only throw for msmq)

[timbussmann]

I'm still +1 on using a default error queue.

Not convinced that the educational value is high enough to warrant this friction

this. The current API is a huge pita. It's easy to forget for existing users, it's unclear what it is for for new users and at that point, I don't think it's the right time to educate them about the error queue. Starting with a new library and first thing is getting an exception is such a bad experience.

for all transports other than MSMQ error is just fine for production use.

why isn't error not fine for msmq? I think the only case is when using SC, because you need to point at the shared error queue, but that's a different fish to fry and not something which needs to be the cores responsibility (and imho not even the transport's). This is an issue for better SC integration in general.

[danielmarbach]

@andreasohlund why does every transport need to set it? Just because of MSMQ?

Then I'd prefer to use it set by default in the core and MSMQ can add a log warn or something similar if it detects it was not explicitly set.

[andreasohlund]

That sounds a good and achieves the same goal

…

On Thu, Feb 2, 2017 at 11:15 AM, Daniel Marbach ***@***.***> wrote: @andreasohlund <https://github.com/andreasohlund> why does every transport need to set it? Just because of MSMQ? Then I'd prefer to use it set by default in the core and MSMQ can add a log warn or something similar if it detects it was not explicitly set. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3647 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAHoZIUs5xvYxle2gZ_THGy-wqItHQxxks5rYay7gaJpZM4H71SP> .

[andreasohlund]

Just adding that we should at least add a backdoor to allow the upcoming development transport to specify a default error and audit queue, no need to burden the users with this. A wellknown settings key would be good enough

[andreasohlund]

After recent discussion we've decided to go ahead and make the core default to error but have MSMQ require an explicit value to be set,

This means that all other transport will no longer need the error queue to be configured.

See https://github.com/Particular/NServiceBus/pull/4636/files for more details

Is anyone opposed to this move please chime in

[andreasohlund]

Assigned to 6.3.0

[SeanFeldman]

So as of 6.3.0 samples should stop using endpointConfiguration.SendFailedMessagesTo(errorQueueName);

[timbussmann]

only if they are not running with MSMQ. But I wonder whether we want to remove them explicitly from the samples, the argument was that we still want to raise a much awareness of the error queue as possible and as the user can't forget to add it, it's fine to keep them on the existing samples I think. But no strong opinion.

[andreasohlund]

My plan was to remove them, for all transports other than msmq the config is just noise? Less code in samples that at not relevant to the sample it self == good thing IMO

…

On Tue, Apr 25, 2017 at 5:50 PM Tim Bussmann ***@***.***> wrote: only if they are not running with MSMQ. But I wonder whether we want to remove them explicitly from the samples, the argument was that we still want to raise a much awareness of the error queue as possible and as the user can't forget to add it, it's fine to keep them on the existing samples I think. But no strong opinion. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3647 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAHoZEWuMX2k23E_SRnyo-51Xr018i47ks5rzhYogaJpZM4H71SP> .