The scenario I have in mind is this: Service Bus is used for instance-to-instance communication, so a Subscription is unique per service instance. The end result is that if an instance does not shut down gracefully, its subscription does not get deleted.
When a service instance "dies" and restarts, previous contents of the subscription are irrelevant and can be discarded.
So, is there a way to set a "time to live" for Service Bus Subscription or simulate something similar, without having to resort to some custom orphan detection mechanism?
Starting with Azure SDK 2.0 this works as expected.
Also, contrary to other reports, in my testing, subscription does not get deleted as long as there is a pending receiver listening to that subscription.
var description = new SubscriptionDescription(topicPath, subscriptionId);
description.AutoDeleteOnIdle = TimeSpan.FromSeconds(600);
namespaceManager.CreateSubscription(description);
that exact feature is on the backlog for one of the next releases. that said, in azure you could use the instance-id fro the role environment to create the name of your subscription and thus have a restarting instance reuse a subscription. the instance-id names are stable.
Edit: The feature is AutoDeleteOnIdle https://learn.microsoft.com/en-us/dotnet/api/microsoft.servicebus.messaging.subscriptiondescription
I had the exact same problem, preview solving it was released beginning of 2013: http://msdn.microsoft.com/en-us/library/microsoft.servicebus.messaging.subscriptiondescription.autodeleteonidle.aspx
It's very easy to use (see example below). Unfortunately it seems that the subscription times out if there is no message published for the AutoDeleteOnIdle period, even if you have some process awaiting for messages (according to Azure Servicebus AutoDeleteOnIdle).
NamespaceManager manager=NamespaceManager.CreateFromConnectionString(serviceBusConnectionString);
if(!manager.SubscriptionExists(topic,subscriptionName))
{
manager.CreateSubscription(new SubscriptionDescription(topic,subscriptionName) {
AutoDeleteOnIdle=TimeSpan.FromDays(2)
});
}
Related
I'm working on an application that deploys and configures resources in Azure. This application will be run by clients and I have no way of knowing whether they'll create new subscriptions, or re-use older ones. Accordingly, I'm registering a set of Resource Providers (RPs) before trying to deploy anything.
As part of my testing, I've found all sorts of RPs that seems to be registered by default. Some of them (e.g. "Microsoft.Authorization" or "Microsoft.Portal") seem crucial to the smooth running of a subscription, so I am loath to start messing about with them. There are others that seem more cryptic (e.g. "Microsoft.Features").
Here's the full list I get when creating a new subscription in Azure today:
Microsoft.ADHybridHealthService
Microsoft.Advisor
Microsoft.AlertsManagement
Microsoft.Authorization
Microsoft.Billing
Microsoft.Cdn
Microsoft.ClassicSubscription
Microsoft.Commerce
Microsoft.Consumption
Microsoft.ContainerRegistry
Microsoft.CostManagement
Microsoft.DocumentDB
Microsoft.Features
Microsoft.GuestConfiguration
microsoft.insights (NB: it has this casing in the portal too)
Microsoft.MarketplaceOrdering
Microsoft.PolicyInsights
Microsoft.Portal
Microsoft.ResourceGraph
Microsoft.ResourceHealth
Microsoft.Resources
Microsoft.Security
Microsoft.SerialConsole
Microsoft.ServiceBus
Microsoft.Sql
Microsoft.Storage
microsoft.support (NB: another with odd casing)
Microsoft.Web
I've no idea if this is standard or can be relied upon. Does it change, for instance, depending on the type of subscription? Or where I'm based?
And which ones are needed? I'm pretty certain my subscription will continue to function without the Service Bus, but what about Billing? (I presume it won't make things free...)
To save me having to do a load of trial and error, is there a definitive, canonical list anywhere of the RPs needed for Azure to work properly? Or even just a canonical list of those included on a new subscription by default.
When ever a new Azure Subscription account is created , list of few Resource providers are available by default.
Some are Registered and some are NotRegistered
I have checked with free and pay-as-you-go Azure Subscriptions, the list of Registered Providers are different for each subscription
Ex: I can see the Microsoft.ServiceBus as Registered in Pay-as-you-go Subscription and as NotRegistered in Free Azure Subscription
In Pay-as-you-go Subscription
In Free Trial Subscription
To list out the available Resource Providers have a look at Available Resource providers
Also refer How to Enable Azure Resource Providers and Azure Resource Providers for more information
For a test I created a free tier IoT Hub and basic service bus. But when I click on the "+ Queue" and fill out all the fields; setting name, size (1gb), message to to live (14 days, default), lock duration (30 seconds, default) and only "Enable partitioning" I get this errormessage when I click create:
The property 'AutoDeleteOnIdle' cannot be set when creating a Queue because the namespace 'x' is using 'Basic' tier.
I should be able to create queues, but not topics with this setup. Are one of the properties of the "Create queue" blade running with a different naming convention from "AutoDeleteOnIdle"?
The property 'AutoDeleteOnIdle' cannot be set when creating a Queue because the namespace 'x' is using 'Basic' tier.
I could reproduce the issue with the following sample when I am using 'Basic' tier.
var namespaceManager = NamespaceManager.CreateFromConnectionString(connectionString);
namespaceManager.CreateQueue(new QueueDescription("testqueue") {
DefaultMessageTimeToLive = TimeSpan.FromDays(14),
LockDuration = TimeSpan.FromSeconds(30),
EnablePartitioning = true,
AutoDeleteOnIdle = TimeSpan.FromMinutes(5) });
}
Exception
After I scale it to standard tier, the above code works fine. If possible, please try to scale to standard tier and check if you could create queue&specify the property AutoDeleteOnIdle.
In my case, I've initially created a service bus with basic. Later I realized that topic is not supported in basic. So, I've deleted the service bus component and recreated a new service bus component with Standard using the same name that I've used before. But, I got above error "SubCode=40000. The property 'AutoDeleteOnIdle' cannot be set when creating a Queue because the namespace 'dev-sb-xxx' is using 'Basic' tier.."
It seems to be a bug to me with azure portal. When I checked scale, it is still shown as basic. I've changed it to Standard and it worked fine.
We are trying to set up a Hybrid Connection from an App Service and the Azure Portal behavior is quite odd. We have done this previously from another subscription; this subscription is part of a CSP (so we can't even try doing it from the old/classic portal).
Blade prompts us to create a new resource group even though the one it defaulted to already exists. (Like it can't populate existing resource groups?)
No locations are provided when navigating to the Location pane, there's a cutoff error message:
"There are no locations available. You may not h..."
We have "owner" role on the subscription.
his subscription is part of a CSA (so we can't even try doing it from the old/classic portal).
Do you mean CSP there, as in Cloud Solution Provider? If so, the resource provider Microsoft.BizTalkServices is not yet available in CSP.
Yes, the error message and how the UI flow is handled could use some improvement.
See this for more:
https://blogs.technet.microsoft.com/hybridcloudbp/2016/06/29/list-of-azure-services-in-csp/
My cloud service is deployed with two instances by default and has auto-scaling feature on which makes Azure to deploy additional instances as needed. I need to signal all instances currently running to invalidate their internal caches. Ideally by POSTing to a public facing url. But Azure load balancer will route the request randomly to one of the instances only.
I probably can utilize Service Bus topics/subscriptions to solve the problem but that looks like overkill. Is there an easier way?
From https://msdn.microsoft.com/library/azure/microsoft.windowsazure.serviceruntime.roleenvironment.changing.aspx:
RoleEnvironment.Changing Event
Occurs before a change to the service configuration is applied to the running instances of a role.
The Changing event and the Changed event are used together to identify and manage configuration changes to the service model. By using the Changing event, an instance can respond to a configuration change [...]
To be honest i can't remember if this is how you do it, but i believe i'm pretty close:
private void RoleEnvironmentChanging(object sender, RoleEnvironmentChangingEventArgs e)
{
if ((e.Changes.Any(change => change is RoleEnvironmentConfigurationSettingChange)))
{
// Deal with e.Cancel
// Invalidate cache
}
}
Here's more on what events are triggered on configuration change:
https://azure.microsoft.com/en-us/blog/responding-to-role-topology-changes/
The following diagram shows which events fire in an example scenario containing a single role. 2 instances are deployed initially, the deployment is then scaled to 4 instances, then back down to 3, and finally the deployment is stopped.
I have this Worker Role which makes use of REST Management API (through https://github.com/Azure/azure-sdk-for-net), whose the most basic pre-requisite is the Subscription ID.
Is there a way to get the Subscription ID from a running (worker) role? E.g. say, through RoleEnvironment?
Sorry Gatis, there is no way to get this via any method provided by Azure*. You would need to pass this information into your role using something like the CSCFG configuration settings.
For a little more context - the subscription ID is only known at the RDFE layer. Once you are in the Fabric layer (ie. your running Worker Role) then there is no concept of a subscription ID. You can see http://blogs.msdn.com/b/kwill/archive/2011/05/05/windows-azure-role-architecture.aspx, process A and steps 1&2, for a little more info.
*If you are using AAD authentication for your Service Management API calls then you could get a list of all subscriptions for that AAD user using 'List Azure Subscriptions' - http://msdn.microsoft.com/en-us/library/azure/dn775050.aspx. With those subscriptions you could enumerate all cloud services and match the deployment ID to the deployment ID for your worker role.
Edit: Typo in first paragraph. Changed 'something like the Subscription ID' to 'something like the CSCFG configuration settings'.