Service Bus

How can we improve the Windows Azure Service Bus?

You've used all your votes and won't be able to post a new idea, but you can still search and comment on existing ideas.

There are two ways to get more votes:

When an admin closes an idea you've voted on, you'll get your votes back from that idea.
You can remove your votes from an open idea you support.
To see ideas you have already voted on, select the "My feedback" filter and select "My open ideas".

Enter your idea

(thinking…)

Enter your idea and we'll search to see if someone has already suggested it.

If a similar idea already exists, you can support and comment on it.

If it doesn't exist, you can post your idea so others can support it.

Enter your idea and we'll search to see if someone has already suggested it.

Cannot pin Service Bus blade to dashboard - missing pin

The pin is missing. See attached
- missing-service-bus-pin.png 7 KB
4 votes

Vote

We're glad you're here
Please sign in to leave feedback

Signed in as (Sign out)

Close

Close

You have left! (?) (thinking…)

0 comments · Bugs · Flag idea as inappropriate… · Delete… · Admin →

triaged · Adminazurecxpuservoice (Product Manager, Microsoft Azure) responded

Thanks for bringing this to our attention. The bug has been moved to the appropriate service area for further review.
Limit the MessagingEntityDisabledException log spam

So the issue at hand is: when we disable a Service Bus Subscription, the ServiceBus listener likes write to logs about - relentlessly. This should be changed so that after a few tries the logging stops. Further explanation below.

Consider this scenario: we have an Azure Function that is triggered by messages arriving to a Service Bus Subscription. Because reasons, we need to temporarily disable a Subscription. As we do this the Service Bus listener starts to spam MessagingEntityDisabledExceptions. In HUGE numbers. A sample of 1 second of logs yielded ~32 logged exceptions, plus the same amount of traces. So imagine 64 log entries per second, per disabled subscription, per Function App instance. The amount is just staggering.

We had to disable a Subscription for nearly 6 days. With AppInsights turned on this resulted in 375 GB of logs! Once we realized this we made an internal rule to NEVER disable a Subscription. It's pretty apparent that the logging is excessive and harmful. It is good and reasonable to know when a Subscription gets disabled but the logging should stop after a few tries as it becomes perfectly apparent that the Subscription is disabled and it's not going to change in the next 1 millisecond.

Solution: either stop logging about it after 'x' number of retries, or simply implement an exponential backoff logic so that at the end we only get like one retry per 10 seconds or similar instead of the non-delayed retry in an infinite loop.

We raised a ticket with Azure Support about this and their recommendation was to raise this issue here while they handle the billing issue caused by the extensive logging. Attached an image of the damage caused as well as a 1 second AI exception log sample that displays the issue.

So the issue at hand is: when we disable a Service Bus Subscription, the ServiceBus listener likes write to logs about - relentlessly. This should be changed so that after a few tries the logging stops. Further explanation below.

Consider this scenario: we have an Azure Function that is triggered by messages arriving to a Service Bus Subscription. Because reasons, we need to temporarily disable a Subscription. As we do this the Service Bus listener starts to spam MessagingEntityDisabledExceptions. In HUGE numbers. A sample of 1 second of logs yielded ~32 logged exceptions, plus the same amount of traces. So…
- appinsights-exceptions-1sec-1instance-anon.csv 231 KB
- appinsights-costs-crop.jpg 43 KB
3 votes

Vote

We're glad you're here
Please sign in to leave feedback

Signed in as (Sign out)

Close

Close

You have left! (?) (thinking…)

0 comments · Bugs · Flag idea as inappropriate… · Edit… · Delete… · Admin →
'Selected Network' means public! unless ip is added

It would be great for Service bus Networking/Firewall screen to be different. IMO at least add a Note on it i.e The "Selected Network" without atleast one ip address, is deemed public!'

This behaviour is very different from other PaaS resources. Other PaaS resources share the same screen (example storage account does not accept internal ip address)

To summarise:

• Weather the radio button is “All networks” or “Selected Networks” then the firewall is open. Until we add atleast one IP to the firewall
• We want to only communicate with service bus via privateendpoint, so should we add the complete internal VNET address in the firewall, in addition to privateendpoint config?

It would be great for Service bus Networking/Firewall screen to be different. IMO at least add a Note on it i.e The "Selected Network" without atleast one ip address, is deemed public!'

This behaviour is very different from other PaaS resources. Other PaaS resources share the same screen (example storage account does not accept internal ip address)

To summarise:

• Weather the radio button is “All networks” or “Selected Networks” then the firewall is open. Until we add atleast one IP to the firewall
• We want to only communicate with service bus via privateendpoint, so should we add the…

1 vote

Vote

We're glad you're here
Please sign in to leave feedback

Signed in as (Sign out)

Close

Close

You have left! (?) (thinking…)

0 comments · Bugs · Flag idea as inappropriate… · Edit… · Delete… · Admin →
Queue Search Behavior Unexpected

Search operates unexpectedly in the service bus queues screen. If I search for a string that I know exists, and there are many queues, and it isn't on the first page of results, it says "No results". But if I click "load more" link it will then appear. Paging should be applied after filtering, when it appears the reverse is true.

1 vote

Vote

We're glad you're here
Please sign in to leave feedback

Signed in as (Sign out)

Close

Close

You have left! (?) (thinking…)

0 comments · Bugs · Flag idea as inappropriate… · Edit… · Delete… · Admin →
Autoscaling on Active Message count fails with an error, when configured for a large set of service bus queues

Issue: when configuring an app service's scale out rule, using the 'Count of active messages in a Queue/Topic' metric, the metrics fail with an error if I select a large number of queues.

Setup:
1. a service bus namespace with a large number of queues (e.g. 100) (see attached screenshot 0101)
2. an app service

Steps to reproduce:
1. in azure portal, load the app service
2. select 'Scale out (App Service plan)
3. choose 'Scale based on a metric'
4. click 'Add a rule' to start defining a new rule
5. in the 'Metric source' picker, select 'Other resource'
6. in the 'Resource type' picker, select 'Service Bus Namespaces'
7. in the 'Resource' picker, select the pre-prepared service bus namespace
8. in the 'Time aggregation' picker, select 'Average'
9. in the 'Metric namespace' picker, select 'Service Bus Namespaces standard metrics'
10. in the 'Metric name' picker, select 'Count of active messages in a queue/topic'
11. Open the Dimension Values picker; the pre-prepared queues are listed, with none yet ticked
12. tick one of the queues; note that in the graph below, the metric value is immediately calculated and displayed
13. tick several more of the queues; the graph updates with the recalculated metric (see attached screenshot 0102)
14. tick a large number of queues. The number required seems to vary, but in my case it took about 55.
Expected behaviour: the metric is recalculated successfully; the graph is redrawn; and the scale rule can be saved and used in practice.
Actual behaviour: noting is plotted on the graph; instead it shows a dark grey block with the words 'Error retrieving data'. (screenshot 0103).
If this scale rule is saved now, the app service remains unscaled no matter how many messages are added to the queues.

See attached:
0101: screenshot showing some of the service bus namespace's long list of queues
0102: screenshot showing the autoscale rule correctly graphing the metric, when not too many queues have been selected
0103: screenshot showing the autoscale rule failing to graph the metric, after more queues have been selected
0104: rest api call failure log, showing the 500 error response received from azure monitor.
Note that that the url for the rest api call is something like 4000 characters long; perhaps this length could be what causes the error?

Issue: when configuring an app service's scale out rule, using the 'Count of active messages in a Queue/Topic' metric, the metrics fail with an error if I select a large number of queues.

Setup:
1. a service bus namespace with a large number of queues (e.g. 100) (see attached screenshot 0101)
2. an app service

Steps to reproduce:
1. in azure portal, load the app service
2. select 'Scale out (App Service plan)
3. choose 'Scale based on a metric'
4. click 'Add a rule' to start defining a new rule
5. in the 'Metric source' picker, select 'Other resource' …
1 vote

Vote

We're glad you're here
Please sign in to leave feedback

Signed in as (Sign out)

Close

Close

You have left! (?) (thinking…)

0 comments · Bugs · Flag idea as inappropriate… · Edit… · Delete… · Admin →

Don't see your idea?

Service Bus

How can we improve the Windows Azure Service Bus?

There are two ways to get more votes:

Cannot pin Service Bus blade to dashboard - missing pin

Limit the MessagingEntityDisabledException log spam

'Selected Network' means public! unless ip is added

Queue Search Behavior Unexpected

Autoscaling on Active Message count fails with an error, when configured for a large set of service bus queues

Feedback

Service Bus

Feedback and Knowledge Base

Searching…

Give feedback

Microsoft Azure

Your password has been reset

How can we improve the Windows Azure Service Bus?

There are two ways to get more votes:

We're glad you're here

Cannot pin Service Bus blade to dashboard - missing pin

We're glad you're here

Limit the MessagingEntityDisabledException log spam

We're glad you're here

'Selected Network' means public! unless ip is added

We're glad you're here

Queue Search Behavior Unexpected

We're glad you're here

Autoscaling on Active Message count fails with an error, when configured for a large set of service bus queues

We're glad you're here

We're glad you're here

Service Bus

Categories

Searching…

Give feedback

Microsoft Azure

Your password has been reset