Community

Loading...

Service Bus

278 Ideas

Provide a proper, linux-based emulator that can be containerized. On-premises editions is not sufficient.

An earlier idea of providing a local emulator and how it was marked as completed really doesn't cut it for what people need a local emulator for.We need to be able to stand up a lightweight, local server during development with minimal effort. An on-premises edition with all the maintenance baggage of a fully fledged product doesn't help.The only way that this suggestion can be marked solved is if a linux-based service bus emulator is created and ideally this would include an accompanying containerization over at docker hub.A subsequent answer of Azure is moving away from emulators doesn't seem consistent considering that the storage emulator continues to get attention.

Eldert Grootenboer

Company Response

Today we have announced the Service Bus emulator, the official announcement can be found at https://techcommunity.microsoft.com/blog/messagingonazureblog/introducing-local-emulator-for-azure-service-bus/4304457.Behind the scenes, our team has poured their heart and soul into making these emulators a reality, and now, we eagerly await your feedback which can be provided through https://github.com/Azure/azure-service-bus-emulator-installer/issues.

Autoscale based on topic-subscription length

Instead of autoscaling on queue length, i would like to be able to scale on topic-subscription length

Eldert Grootenboer

Company Response

This feature in our backlog, however we currently don't have an ETA on when development might start on this. For now, to help us give this the right priority, it would be helpful to see others vote and support this feature, as well as explain their scenarios.

Provide gracefull shutdown feature to Message Pump in Queue and Subscription Clients

There is not a good way to deal with a graceful shutdown of a Worker role using the OnMessage approach of processing queue messages off the service bus. It would be nice if you could call StopProcessing, or something similar on the QueueClient or SubscriptionClient so that they would stop their internal receive loop, but finish processing the messages they may already be processing. A count property of active processing messages would also be helpful so that in an OnStop method on the worker role you could call the StopProcessing and enter a loop till the active processing messages was zero.Perhaps actually creating a new class called a MessagePump which accepted a QueueClient or SubscriptionClient as part of the constructor would be a good route to provide a better break down of responsibilities.

Eldert Grootenboer

Company Response

This is already supported in our latest SDK. Please switch to microsoft.azure.servicebus to use this functionality.

Queue purge

Provide an API for purging of a queue, without having to delete and recreate the queue.

Company Response

We have recently released a new batch delete feature, a new feature that lets you delete messages in bulk from your Service Bus entities. Batch delete helps you to delete multiple messages from a messaging entity in one operation, instead of deleting them one by one. Since deletion is done at service side, you don't need to receive the messages before deleting them. For more information, check the announcement and the documentation.

Using a filter with EventHub data

Will we be able to use a filter in the future for the EventHub data? I'm designing a new solution for a customer and it looks like EventHubs are great for sending and receiving our near-realtime data. Downside is when receiving the data, we receive all data of all our devices in the world. Most of the time, our clients only want to see data of one (or a few) device. We could of course filter the data by ourselves, client side, but this would cost a lot of bandwith.

Company Response

Filters are in our roadmap. Filters will be tied to Consumer Groups.

monitor subscriptions

My customer would like to be able to monitor subscription metrics through azure monitor. Currently there is no way to see if a subscription is successfully processing messages. A user can monitor topics to see that it has sent outgoing messages to subscriptions but not monitor the subscription to see that it is functioning and provide alerts to notify users of that inactivity.

Company Response

Thank you everyone for your feedback on this item so far. We are currently actively working on a feature that brings subscription level metrics to Log Analytics. This feature is currently under design, and we expect to have more updates in the next couple of months.

Implement queue priority pattern

Implement priority queue pattern, to use one queue or topic subscription that can reorder its messages according to theirs priority.Pattern description https://msdn.microsoft.com/en-us/library/dn589794.aspx

Under Review

All Ideas

Eldert Grootenboer

Company Response

11 months ago

Thank you for your feedback on this item so far, it helps us in our efforts to continuously prioritize the different requests we get from all our various feedback channels. We have added this feature in our backlog, however we currently don't have an ETA on when development will start on this. For now, to help us give this the right priority, it would be helpful to see others vote and support this feature, as well as explain their scenarios.For now, we still recommend the use of Topics with separate subscriptions for priority and non-priority messages, or alternatively use sessions for this. The reason behind this is that we believe that with different priorities will also require different handlers and that the relative system capacity reserved for those handlers is also different. This is especially important in systems with long processing times, as even priority messages might have to wait for a long time for the previous process to be completed.

BrokeredMessage.Defer(); should send a message to the back of the line

I use the Azure Service Bus in a geographically distributed environment. I also process messages in vertically and horizontally scaled out services.Very often I will receive a message from the service bus for processing, but don't have enough information to complete the processing, (most of the time this is because I am waiting for SQL replication across continents) so I'll have to try again later.Seems like a job for BrokeredMessage.Defer()! But alas, that causes the message to immediately get returned when I call Client.Receive(); even if there are thousands of messages in the queue / subscription that I have not even touched yet. So I end up pulling down the same message(s) rapidly and hitting the SQL server trying to lookup information that isn't there yet, while there are messages in my queue that I could potentially have enough information available to complete their processing.The way I have gotten around this, is to let the brokeredMessage simply time out. But this is a terrible approach.What would be nice, is if the BrokeredMessage.Defer(); call would send the message to the back of the bus so to speak, so that messages that I have not tried processing yet can get a chance before I try that particular message again.Another useful idea would be to add an overload to BrokeredMessage.Defer(); that accepts a TimeSpan. That way I can tell the service bus don't redeliver this message until that time period has passed

Eldert Grootenboer

Company Response

We are currently doing active development on this feature, and expect to have more to share around its release in the next couple of months.

Event Grid integration with Service Bus Standard Edition

It would be good if Event Grid is integrated with Service Bus Standard Edition . As of now Event grid can listen to only premium tier service bus events. By supporting Standard edition of Service bus ,it will increase event driven messaging adoption .�

Company Response

There are no plans to bring this to Service Bus standard.

Increase the maximum message size for Premium

Premium is currently limited to a maximum message size of 1 MB. It would be great if you increased the maximum message size for Premium to 10 MB.I see that there was a more general request regarding this that has been closed, https://feedback.azure.com/forums/216926-service-bus/suggestions/3933438-increase-the-256k-maximum-message-size-limit-of-br, but I assume that was before Premium was thought of.

Completed

All Ideas