Azure Service Bus : Queue/Topic name character limit (50)

[John Fly]

https://msdn.microsoft.com/en-us/library/azure/ee732538.aspx

Just a comment/question:

Today we had a classic "Works on my machine." moment.

When we published to Azure WebSites, we started having tons of issues which we finally tracked down to our Azure Service Bus Queue and Topic creations.

Apparently there is a 50 character limit on ASB Queues and Topics, and our last change set had a long event name, which worked fine for running locally, but died as soon as we deployed.

What happened was when NSB appended the machine name to the endpoint name, it went over 50 characters.  This didn't show up on local testing because all our local box names are short.

Does anyone know if there is a plan to handle this in NSB, or should I file a new issue?

[Sean Feldman]

Hi John,

Queues and Topic can go up to 260 characters. Subscriptions only 50. 

What Azure ServiceBus transport is doing is replacing a long name with a deterministic GUID. 

I did notice that our queue and topic max length is no longer matching what Azure SB is allowing.

I'm opening an issue 

https://github.com/Particular/NServiceBus.AzureServiceBus/issues/28

please continue conversation on GitHub and if you could provide the following info on the issue: version of NSB and transport, endpoint name/length you had, how did you run/test it locally.

Thank you.

[Denny Crane]

The subscription names are still limited to 50 characters, aren't they? Would it be of any use if the new netcore SDK perhaps had the means of predetermining the UUID that's going to be used for the subscription? So then, for example, NSB's ASB SDK could get the UUID and use it as an alias to the FQN? Not sure if that makes sense, since I'm not sure how NSB is using that name currently. But assuming it's using it ask for messages and pair them to the handler, I figured it could use this translator to bridge that gap. If it would be useful, since MSFT is currently rewriting the SDK for netcore, maybe it would be good request it on the projects GitHub.

[Sean Feldman]

The subscription names are still limited to 50 characters, aren't they?

That's correct.

Would it be of any use if the new netcore SDK perhaps had the means of predetermining the UUID that's going to be used for the subscription?

That's probably more of a question for Microsoft team working on the .NET Standard client.

They are also aware of the implications it could have on the broker.

I suggest you raise this question  with them in https://github.com/Azure/azure-service-bus/issues (server-side issues tracked in this repo).

Please note that NServiceBus Google Group has moved to https://discuss.particular.net.

Sean

[Jeremy Stafford]

I was actually in the middle of posting the question to them, but the only reason I even care right now is for NSB purposes. I'm wondering if that would allow NSB to use both long subscription names while simultaneously honoring the 50 character limit with ASB.

--
You received this message because you are subscribed to a topic in the Google Groups "Particular Software" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/particularsoftware/XuHp_8wZ09o/unsubscribe.
To unsubscribe from this group and all its topics, send an email to particularsoftware+unsub...@googlegroups.com.
To post to this group, send email to particularsoftware@googlegroups.com.
Visit this group at https://groups.google.com/group/particularsoftware.
To view this discussion on the web visit https://groups.google.com/d/msgid/particularsoftware/97da654b-e99a-4eb1-8d25-dc757a55e64a%40googlegroups.com.

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

--

(Love) A temporary insanity curable by marriage.
-- Ambrose Bierce

[Sean Feldman]

If such a functionality is added, the transport could take advantage of it.

This would probably still not change a lot API wise, as it would still be done through sanitization API where you'd be able to plug in a new strategy based on the native ASB API.