I created a service bus account with Basic tier and tried to create a Topic but I saw that it was not possible due to the Basic tier. So I deleted this service bus and created another one with the same name, but this time with the tier as Standard. Now when I try to create a topic I get the message:
SubCode=40000. Cannot operate on type Topic because the namespace 'XXXX' is using 'Basic' tier.
But it´s Standard as you can see on the image:
There are only two hard things in Computer Science: cache invalidation and naming things.
-- Phil Karlton
Service Bus is not an exception. Your best bet at this point is to contact Azure support directly or via Twitter.
Related
I have nearly identical service buses in 2 separate regions. I am trying to make them be more region agnostic for consuming applications.
While looking into things like Azure service bus geo-disaster recovery and message replication and cross-region federation and how complicated they are, I was thinking instead that I could create a service bus client that would just read from the same topic/subscription name in separate regions and treat them as if they came from the same region.
While I'm sure this can be implemented, I was wondering, does this functionality exists in any current Microsoft libraries? Basically, if message A get published to the east topic/subscription and message B gets published to the Central US topic/subscription, then the client would receive A and B. The order is not important.
Thanks!
Some sort of functionality has existed in the track 0 SDK of Azure Service Bus SDK for failover but not concurrent execution. As it was a client-side feature, it did not get much traction and was very confusing and complicated.
NServiceBus had a legacy Azure Service Bus transport that supported using more than one namespace concurrently. The feature was deprecated as it was also more of a trouble than good. Not to mention the fact that Service Bus has introduced the Premium tier which would handle availability better than multiple standard namespaces together. On top of that, add availability zones and it's hands down a better option than the complexity of setting up multiple receivers.
In case your namespaces are identical, I would suggest consolidating them. One of the strategies would be to "forward" messages from one namespace to another using some processor as there's no cross-namespace forwarding.
I'm trying to create a table of comparison of different messaging queue, from opensource to proprietary. and I'm trying to identify the issues and disadvantages of Azure Service Bus without availing the standard and premium tier. I would like to ask this question to those who experienced implementing it on their own application.
I tried researching for related topics but i cant find reliable resource.
I'm expecting a list of possible issue and disadvantages in general in any of this areas; features, limitations, experience, maturity, community, and performance.
Service bus is just a medium to deliver messages from issuer to the receiver. it doesnt matter when they both are as long as they can talk to the service bus. your application can talk to service bus from inside the container just fine.
I've got 2 Service Bus namespaces, both on the Standard Tier.
The older of the two only shows the Queues option and the option to create a Topic is disabled, however there are existing Topics in the namespace and these all work correctly.
The newer one which was created today has Topics enabled.
Both of them show as Standard Tier in the Portal:
Namespace missing Topics:
Namespace with Topics:
If I try to change the older one to Basic, it fails due to the existing Topics.
My theory is that this is a bug in the Portal and, while the underlying Azure infrastructure and the Scaling section of the portal know that this is a Standard Tier, that some part of it is not recognizing this, thus the missing Topics.
It should also be noted that if I generate an Automation Script, it wants to create this namespace as a Basic SKU but the other one as a Standard. It may be that at some point in the past (many years ago), this was a Basic tier.
So my question is, is there anything else I can check on the older namespace that may be incorrect that I can resolve or is this a bug in the Portal?
I just came into the same issue, I got a Service Bus resource from our Dev Ops team and it turned out that the topic feature is missing. The reason is that the pricing tier was basic.
I am creating an Azure Service Bus with the Fluent SDK. I want to give my service bus a specific name and increment by one if the name is unavailable.
The problem I am having is that I don't actually know if the name is unavailable at the time of creation.
I'm using this to create a service bus:
var serviceBusNamespace = azure.ServiceBusNamespaces
.Define(serviceBusName)
.WithRegion(Region)
.WithExistingResourceGroup(resourceGroup)
.WithSku(NamespaceSku.Standard)
.Create();
If I run this code for two different resource groups using the same serviceBusName, I get a service bus created in both resources groups without error. However when I go to the Azure portal the first service bus opens fine, but I get an error saying 'Not Found' when trying to open the second.
I understand that servicebus names must be unique across all of Azure, but
Why is the Fluent SDK allowing me to create the second service bus with the same name?
How can I check of the name is unique before creating the service bus?
I tried to ping the service bus URL to see if it exists. For example I tried this, for a URL like serviceBusName.servicebus.windows.net, but that failed.
Why is the Fluent SDK allowing me to create the second service bus with the same name?
You should raise this as an issue with the team that develops the library. In this case, Fluent SDK is produced by .NET Libraries for Azure team. Issue tracker is available here. When raising an issue, label it with Service Bus.
How can I check of the name is unique before creating the service bus?
Operation to provision a new namespace could be enqueued internally. Therefore, when you query for a namespace existence, you might get a negative response while backend is spinning it up. One of the requests will succeed, while another will fail. You'd need to create and query for a result after, checking the status.
I am old school Windows Azure Architect. Using service bus topics to pass messages to worker role.
How to publish more thank 256KB message to a subscription? I know
there is a premium tier service bus which allows 1MB message, but
1MB limit will may also not be enough.
If you're trying to send a message that is more than 256KB/1MB and avoid claim check pattern, then I'm questioning the design. ASB is about messaging, not data transfer.
The current ASB client (WindowsAzure.ServiceBus) doesn't make claim check pattern implementation trivial, indeed. The good news is that with the new client (Microsoft.Azure.ServiceBus) it's much simpler. You can leverage Extensions API and either use claim check pattern implementation provided by ServiceBus.AttachmentPlugin or extend it and allow multiple Storage accounts to be leveraged.