I have been testing around with the Azure App Services and got this error
App Service Plan Create operation is throttled for subscription.
As I understand I created too many apps in a short period, how long until I can create a new app again?
Thank you
I began receiving this error, but without the Retry-After property in the response. After working with Azure support, it turns out newly-created subscriptions take a while to fully allocate in the background. We had to wait 48 hours before the throttling error would go away, and that was what Azure support validated with us.
Once the 48 hours passed (and the new Azure sub was presumably complete in its creation), we no longer received the errors.
As I understand I created too many apps in a short period, how long
until I can create a new app again?
We dont have any ideal time that how long until you have to wait to create a new app again.
Throttling happens at two levels. Azure Resource Manager throttles requests for the subscription and tenant.
When you reach the limit, you receive the HTTP status code 429 Too many requests. The response includes a Retry-After value, which specifies the number of seconds your application should wait (or sleep) before sending the next request. If you send a request before the retry value has elapsed, your request isn't processed and a new retry value is returned.
You can determine the number of remaining requests by examining response headers. Read requests return a value in the header for the number of remaining read requests. Write requests include a value for the number of remaining write requests.
You refer this documentation,on how to Retrieving these header values in your code.
Related
I'm facing intermittently delay with polling email messages via Gmail API from GSuite user's inbox. Those calls origin from automatic jobs and use multiple G-Suite users to disperse the work and avoid reaching Quota limits.
However, there are still delay of at least 3 minutes in reading the email. Investigating message email headers showed neither errors (429) or delay time, nor quota limits are being reached.
I examined the push notification method and I'm limited to use it.
Are limit units calculated according to domain rather than per G-Suite user so I'm indeed reach quota?
What else can cause those delays?
The Gmail API has usage limits per method and per user.
Email sending limits are calculated per user per day, not per domain.
Limit units are calculated from all requests made from your application per day
You can check your quota in the Cloud console, choosing your project and API (in this case Gmail).
In my case, I could clearly see the email inside the 'Sent' folder but the recipient had not got any email, so I knew the limits for using the API had not been crossed. It was spam protection taking a ton of time to figure out if the sent email was spam or not. The most common case would be if your emails are all similar with a link in them. I removed the hyperlink in my template email notification and it started working again without any delay.
Scenario
When business transactions are performed, we're supposed to make that data available to end clients.
Current Design
Our web app publishes transaction messages are added to a topic on the Azure Service Bus.
We expose APIs to clients through which they can consume the data from those transactions.
Upon calling these APIs, we read the messages from the Subscription and return it to the client.
Problem
We want a guaranteed delivery - we want to make sure the client acknowledges the delivery of the data. So we don't want to remove the message from the subscription immediately. We want to keep it until the client acknowledges it.
So we only want to do a "Peek" instead of "Receive".
So the client calls the first API, to get the data, where we do a Peek.
And once the client has received the packets, the client would call a second API, to acknowledge.
At this point, we want to remove the message from the Subscription, making it Complete.
The current design of the Service Bus Message Receiver is that, a Complete can be performed only using the same Receiver instance that performed the Peek, as per the documentation, and we also observed the same when we tried it out.
Both the APIs, are two separate APIs and we cannot do the Peek and Complete using the same instance of the Receiver.
Thinking about options to somehow make the Receiver as a Singleton, across APIs within that App Service.
However this will be a problem when the App Service scales out.
Is there a different way to achieve what we're trying to do here ?
There is an option available in Azure Service Bus to defer messages. Once a message is deferred, it can be received with the help of it's sequence number.
The first client should receive the message and instead of completing it, it should defer it and return it.
The second client (which has sequence number) can receive the message from the Subscription. Refer here for more details.
Another option would be to not use a Service Bus Client on your backend and instead your clients could directly work with Service Bus using its Service REST API (assuming they can't use the AMQP client if I am understanding your scenario correctly).
There are APIs to
Peek-Lock
Renew Lock
Unlock
Delete (Complete)
You could also proxy these requests if you'd like using your backend itself or a service like APIM if you are already using it.
PS: Cross posting the answer for the same query on the MSDN forum
Does anyone know if Azure Bot's Directline call to refresh token is free or will use the messaging quota? The free one has 10,000 messages/month and S1 package is RM$2.10 per 1,000 messages. This is because the token will expire after 30 minutes, and we want to auto refresh it before 30 minutes.
Does anyone know where to check the quota usage of the 10,000 messages?
In the Azure Portal's Web App Bot's Analytic page, it shows the number of activities, not sure if it is same as the 10,000 messages?
Thanks
Each activity is a message. From this page:
Bots communicate with the Bot Service channels by sending Activity
objects to the channel endpoint via HTTP POST, and by Activity objects
being sent to the Bot’s endpoint via HTTP POST. Each of these Activity
POSTs is a message.
No, they do not count. The calls to refresh the token are not activities, therefore not messages.
Yes, the analytics page is the correct place.
While implementing the DocuSign we are getting The maximum number of hourly API invocations has been exceeded error message sometimes this is because of the API call rate exceed per 1 hour. Anyone have any idea how to increase the API call rate per account from 1000 to 5000?
You need to contact your DocuSign's Account Manager with a valid usecase why you need the API limit to be increased to 5000. As a defensive check you should always read the header in the API response, DocuSign provide the data as whats your call limit, how many calls are remaining and what is next schedule counter reset for you. By reading these header values, you can make your application pause for sometime so that you don't hit threshold limit and handle the limit scenario properly.
Along with your DocuSign Account Manager, you can contact support#docusign.com also.
I am using windows azure service bus for messaging. We have created web api to pull the messages from service bus. Mobile app is using this web api for getting messages. We are using PeekLock mode in subscription client and the lockduration is 5 minutes.
On client side if messages takes more than 5 minute to process then message will unlock. So before it unlock we want to renew the Lock. So we have created another web api to renew the lock. In web api we are passing the LockToken. But when we use subscriptionClient.RenewMessageLockAsync(new Guid(lockToken)), it throws error "The lock supplied is invalid. Either the lock expired, or the message has already been removed from the queue" before the Lock expiration time. We are initiating the renew lock before 1.5 min of message LockUntilUtc time.
My question here is can we renew the message lock before it expirytime? And if yes then why azure service bus throwing lock expired error? Please help me to understand this renew lock things.
You can extend the lock manually, but you need to make sure it happens before the server is unlocking it.
Another option, which I personally prefer more, is to use OnMessage API. It allows you to specify OnMessageOptions.AutoRenewTimeout which will be an extension time in case your callback that handles the message is not done. OnMessage API will also ensure that extension is invoked if you're about to exceed lock duration. This way you also won't need to have another web API, which sounds a little off.
Have a look at the recent post I wrote on this API.