Azure Topic Subscription Names Limited to 50 Characters

[onesadjam]

When using Azure Service Bus to manage PubSub, the name of the subscription to a topic is limited to 50 characters. The naming convention for topic subscriptions is [endpoint queue name].[message type]. We have rather descriptive queue and message names, and ran into this limitation. The endpoint continued to run even though the subscription could not be made.

Recommendations:

• Fail fast if the topic subscription cannot be made
• Lobby Microsoft to increase the string length of topic subscription names :-)

[johnsimons]

@onesadjam Feel like sending us a PR to fix this?

[SimonCropp]

@onesadjam

"Lobby Microsoft to increase the string length of topic subscription names " that is a great idea. please attach the MS connect issue url and I will vote for it

"Fail fast if the topic subscription cannot be made" fail fast is problematic. we have discovered this the hard way #1137 As @johnsimons suggested could you put together a PR that illustrates how you would handle this

[onesadjam]

I submitted an idea on Connect, feel free to pile on: http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/4175354-increase-the-maximum-length-of-the-name-of-a-topic

I've not performed a pull-request to this project, or any project on github for that matter. Do you have guidelines that I should reference to get started?

[SimonCropp]

@onesadjam here you go https://github.com/NServiceBus/NServiceBus/blob/develop/CONTRIBUTING.md

[SimonCropp]

#1341

[SimonCropp]

@onesadjam how did you go?

[onesadjam]

I don't think I'm going to be able to supply a PR. We are currently
working around this issue by using names that do not result in overflowing
the subscription name length limit. The issue posted to MS connect
received 4 votes and a comment from an MS rep that they are reviewing it
for future release.

On Sun, Aug 18, 2013 at 10:02 PM, Simon Cropp notifications@github.comwrote:

@onesadjam https://github.com/onesadjam how did you go?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1300#issuecomment-22847365
.

[andreasohlund]

Both websphere and windows service bus is solving this by generating
shorter q names using deterministic guids

https://github.com/Particular/NServiceBus.WebSphereMQ/blob/master/src/NServiceBus.Transports.WebSphereMQ/WebSphereMqAddress.cs#L47

Would that work here?

On Mon, Aug 19, 2013 at 5:05 AM, onesadjam notifications@github.com wrote:

I don't think I'm going to be able to supply a PR. We are currently
working around this issue by using names that do not result in overflowing
the subscription name length limit. The issue posted to MS connect
received 4 votes and a comment from an MS rep that they are reviewing it
for future release.

On Sun, Aug 18, 2013 at 10:02 PM, Simon Cropp notifications@github.comwrote:

@onesadjam https://github.com/onesadjam how did you go?

—
Reply to this email directly or view it on GitHub<
https://github.com/Particular/NServiceBus/issues/1300#issuecomment-22847365>

.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1300#issuecomment-22848570
.

http://andreasohlund.net
http://twitter.com/andreasohlund

[onesadjam]

That looks like it would work, but it would make upgrading from the current
NSB to the new pattern painful. The steps would be:

• Delete existing subscription (and start missing events due to this)
• Restart endpoint to force the subscription to be recreated
• Modify the filter rule for the subscription (the filter rule created in
  the previous step enforces that the subscriber will only receive messages
  when the publisher is referencing the same build of the message definition
  assembly as the subscriber).

On Mon, Aug 19, 2013 at 3:38 AM, Andreas Öhlund notifications@github.comwrote:

Both websphere and windows service bus is solving this by generating
shorter q names using deterministic guids

https://github.com/Particular/NServiceBus.WebSphereMQ/blob/master/src/NServiceBus.Transports.WebSphereMQ/WebSphereMqAddress.cs#L47

Would that work here?

On Mon, Aug 19, 2013 at 5:05 AM, onesadjam notifications@github.com
wrote:

I don't think I'm going to be able to supply a PR. We are currently
working around this issue by using names that do not result in
overflowing
the subscription name length limit. The issue posted to MS connect
received 4 votes and a comment from an MS rep that they are reviewing it
for future release.

On Sun, Aug 18, 2013 at 10:02 PM, Simon Cropp notifications@github.comwrote:

@onesadjam https://github.com/onesadjam how did you go?

—
Reply to this email directly or view it on GitHub<

https://github.com/Particular/NServiceBus/issues/1300#issuecomment-22847365>

.

—
Reply to this email directly or view it on GitHub<
https://github.com/Particular/NServiceBus/issues/1300#issuecomment-22848570>

.

http://andreasohlund.net
http://twitter.com/andreasohlund

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1300#issuecomment-22855314
.

[andreasohlund]

Since we only do this for names > 50 there is no backwards compatibility issue?

Sent from my iPhone

On 19 aug 2013, at 15:29, onesadjam notifications@github.com wrote:

That looks like it would work, but it would make upgrading from the current
NSB to the new pattern painful. The steps would be:

• Delete existing subscription (and start missing events due to this)
• Restart endpoint to force the subscription to be recreated
• Modify the filter rule for the subscription (the filter rule created in
  the previous step enforces that the subscriber will only receive messages
  when the publisher is referencing the same build of the message definition
  assembly as the subscriber).

On Mon, Aug 19, 2013 at 3:38 AM, Andreas Öhlund notifications@github.comwrote:

Both websphere and windows service bus is solving this by generating
shorter q names using deterministic guids

https://github.com/Particular/NServiceBus.WebSphereMQ/blob/master/src/NServiceBus.Transports.WebSphereMQ/WebSphereMqAddress.cs#L47

Would that work here?

On Mon, Aug 19, 2013 at 5:05 AM, onesadjam notifications@github.com
wrote:

I don't think I'm going to be able to supply a PR. We are currently
working around this issue by using names that do not result in
overflowing
the subscription name length limit. The issue posted to MS connect
received 4 votes and a comment from an MS rep that they are reviewing it
for future release.

On Sun, Aug 18, 2013 at 10:02 PM, Simon Cropp notifications@github.comwrote:

@onesadjam https://github.com/onesadjam how did you go?

—
Reply to this email directly or view it on GitHub<

https://github.com/Particular/NServiceBus/issues/1300#issuecomment-22847365>

.

—
Reply to this email directly or view it on GitHub<
https://github.com/Particular/NServiceBus/issues/1300#issuecomment-22848570>

.

http://andreasohlund.net
http://twitter.com/andreasohlund

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1300#issuecomment-22855314
.

—
Reply to this email directly or view it on GitHub.

[onesadjam]

True, if the implementation is to only apply the hash when the name exceeds
the limit it would eliminate the backwards compatibility issue.

On Mon, Aug 19, 2013 at 9:38 AM, Andreas Öhlund notifications@github.comwrote:

Since we only do this for names > 50 there is no backwards compatibility
issue?

Sent from my iPhone

On 19 aug 2013, at 15:29, onesadjam notifications@github.com wrote:

That looks like it would work, but it would make upgrading from the
current
NSB to the new pattern painful. The steps would be:

• Delete existing subscription (and start missing events due to this)
• Restart endpoint to force the subscription to be recreated
• Modify the filter rule for the subscription (the filter rule created
  in
  the previous step enforces that the subscriber will only receive
  messages
  when the publisher is referencing the same build of the message
  definition
  assembly as the subscriber).

On Mon, Aug 19, 2013 at 3:38 AM, Andreas Öhlund <
notifications@github.com>wrote:

Both websphere and windows service bus is solving this by generating
shorter q names using deterministic guids

https://github.com/Particular/NServiceBus.WebSphereMQ/blob/master/src/NServiceBus.Transports.WebSphereMQ/WebSphereMqAddress.cs#L47

Would that work here?

On Mon, Aug 19, 2013 at 5:05 AM, onesadjam notifications@github.com
wrote:

I don't think I'm going to be able to supply a PR. We are currently
working around this issue by using names that do not result in
overflowing
the subscription name length limit. The issue posted to MS connect
received 4 votes and a comment from an MS rep that they are
reviewing it
for future release.

On Sun, Aug 18, 2013 at 10:02 PM, Simon Cropp <
notifications@github.com>wrote:

@onesadjam https://github.com/onesadjam how did you go?

—
Reply to this email directly or view it on GitHub<

https://github.com/Particular/NServiceBus/issues/1300#issuecomment-22847365>

.

—
Reply to this email directly or view it on GitHub<

https://github.com/Particular/NServiceBus/issues/1300#issuecomment-22848570>

.

http://andreasohlund.net
http://twitter.com/andreasohlund

—
Reply to this email directly or view it on GitHub<
https://github.com/Particular/NServiceBus/issues/1300#issuecomment-22855314>

.

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1300#issuecomment-22872077
.

[SimonCropp]

moved to Particular/NServiceBus.Azure#19

[aanttila]

Since the original User Voice for increasing the length of queue names was closed because it was submitted to the wrong team, I've created a new request here:
https://feedback.azure.com/forums/216926-service-bus/suggestions/18552391-increase-the-maximum-length-of-the-name-of-a-topic