I've deployed a Microsoft-Cognitive Translator Text API environment in Azure. I've been following the documentation, and landed on the Getting a token on this interactive page section. Inserting my private key in the field has the process wait very long and fail, most of the time. I was able to get a result a few times, but it's very rare.
Using the command line curls, I've been getting 500s, or SSLRead errors. Is the service down ATM, or was it moved to somewhere else ?
See https://azure.microsoft.com/en-us/status/history/:
2/14 Cognitive Services | Resolved
Summary of impact: Between as early as 22:00 UTC on 13 Feb 2017 and
4:00 UTC on 14 Feb 2017, a subset of customers using Cognitive
Services may have received intermittent timeouts or errors when making
API requests or generating tokens for their Cognitive Services.
Preliminary root cause: At this stage Engineers do not have a
definitive root cause.
Mitigation: Engineers scaled out the service in order to mitigate.
Next steps: Engineers will continue to investigate to establish the
full root cause.
Related
I'm trying to allow my search indexer to connect to a cosmosdb behind a vnet. When adding a shared private access, the provisioning state is set to failed, without giving me an explanation. I have a private endpoint on the CosmosDB setup already. How do I make this work?
I had the same issue occur on the same day as you reported it.
I had been setting up running this connection via Azure Pipelines the day before but suddenly the same Pipeline stopped working.
I raised it as an issue with MS and it was quickly reproduced by the 1st line and passed onto escalation engineers who confirmed there was a recent change in the Fluent SDK used, when we initiate an ARM deployment for Shared Private Link resources we end up specifying both template link and template id (incorrectly/by accident). As a result, customers creating SPL resources are failing to do so with a 500.
I am told there is a world-wide fixed being rolled out and to be completed on Monday pacific time.
When using BlazeDS (Flex app) to send dates to CF, and the date sent is within Daylight Saving Time, CF fails with an error:
[BlazeDS] Error deserializing client message.
coldfusion.runtime.locale.CFLocaleBase$InvalidDateTimeException: July 8, 2016 6:00:00 PM EDT is an invalid date or time string.
My guess is that this is likely caused by CF 2018 using Java 10 which has an issue in CLDR using three character time zone formats. (We are US shop). Even having the standard JVM switch -Djava.locale.providers=COMPAT,SPI it does not work, fails every time.
Does anyone have any ideas how to resolve? I am about to try using a separate JVM as a test, but not sure whether that will work or not. I suspect BlazeDS is not playing nicely with JVM (using its own, maybe?)
Here is a zip file containing sample project, see "ADDITIONAL" sub-folder for logs, screen shot of proxy AMF dump, etc. Copy the Additional -> remotingDateTest folder to your web root and adjust the RemoteObject in the project application file... https://www.dropbox.com/s/xte4bqrkp7loefi/Remoting%20Test.zip?dl=0
Adobe actually provided me with the answer: add the following to my JVM args (it works!):
-Duser.timezone=NewYork
As of yesterday, when I publish the (current) Product and its API, the deployed Assembly is not updated and what is running is from an earlier state - most likely from early December. The APIC domain was created at the end of Nov, so what I is deployed could even be the initial deployment.
As a test, I changed the API's description (add 'XXX') and changed a Gateway script to add XXX to a 'console.warn' at the start of the Assembly. The description change can be seen in Portal, but there is no 'XXX' visible in the DP log. I set DP log level to 'debug', but none of the 'tracing' statements added in Dec can be seen.
Does anyone have any ideas as to how I can resolve this? Or, how can I see the API's deployed code? I've looked in the DP File Management, but everything is dated at then end of Nov.
[EDIT]
Catalogs are in Dev mode, so I change and publish using same version. I have just done a series of tests using the api referred to above (VAT-Num-Check) (which is our first 'real' api) and an older trivial one that just divides two numbers. The Sandbox catalog is associated with the DEV gateway, and the SIT catalog, with the SIT gateway.
The other kind of corruption is, after deploying a new api, calling it results in 404 'No resources match requested URI'.
My conclusions are:
Something has broken in Mgmt server and/or DP APiC Gateway. Once code has been deployed to DP, it can't be changed or deleted. Changes in Portal are correct.
The possible exception is that the deployment of the VAT-Num-check API appears to have reverted to an earlier version after a CLI publish to the SIT Gateway this morning.
[/EDIT]
Background:
I have been creating a Windows script to publish draft Product/APIs and then run Postman tests. This means that I have been performing a lot of publish actions to DP (V5 type). On Monday evening, in my last run, the Postman tests all worked. Yesterday morning, some failed.
Back in early Dec, I made a change so that all JSON error messages in user responses used error as the 'prefix' to the message contents. Before that, some used message and some used reply. The reason for the failures is error messages have reverted to using the earlier 'prefix'.
API Connect 2018.3.7 went out of support on November 15, 2018. You'd need to upgrade to 2018.4.1.x, which will be supported for a longer term.
If you still have the issue at that point, then please open a support ticket for further investigation.
I have an application that's been running since 2015. It both reads and writes to approx 16 calendars via a service account, using the Google node.js library (calendar v3 API). We also have G Suite for Education.
The general process is:
Every 30 seconds it caches all calendar data via a list operation
Periodically a student will request an appointment "slot", it first checks to see if the slot is still open (via a list call) then an insert.
That's all it does. It's been running fine until the past few days, where API insert calls started failing:
{
"code": 403,
"errors": [{
"domain": "usageLimits",
"reason": "quotaExceeded",
"message": "Calendar usage limits exceeded."
}]
}
This isn't all that special - the documentation has three "solutions":
Read more on the Calendar usage limits in the G Suite Administrator
help.
If one user is making a lot of requests on behalf of many users
of a G Suite domain, consider using a Service Account with authority
delegation (setting the quotaUser parameter).
Use exponential backoff.
I'm not exceeding any of the stated limits as far as I can tell.
While I'm using a service account, it isn't making a request on behalf of a user. The service account has write access to the calendar and adds the user as an attendee
Finally, I do not think exponential backoff will help, although I do not have this implemented. The time between a request to insert and the next insert call is measured in seconds, not milliseconds. Additionally, just running calls directly on the command line with a simple script produce the same problem.
Some stats:
2015 - 2,466 inserts, 186 errors
2016 - 25,747 inserts, 237 errors
2017 - 42,815 inserts, 225 errors
2018 - 41,390 inserts, 1,074 errors (990 of which are in the past 3 days)
I have updated the code over the years, but it has remained largely untouched this term.
At this point I'm unsure what to do - there is no channel to reach Google, and while I have not implemented a backoff strategy, the way timings work with this application, subsequent calls are delayed by seconds, and processed in a queue that sequentially processes requests. The only concurrent requests would be list operations.
My app has been working fine since I changed my free account to a Pay-As-You-Go account but yesterday I started receiving the Access denied due to invalid subscription key error
I haven't changed anything. What can be the source of this error?
Microsoft CRIS servers were experiencing down time starting from ~ 10 pm GMT (according to my observation) on Wednesday 04/19 till 9 am GMT Thursday 14/20. I've experienced problems with log in, deployment access. But some of their servers went back and I was able to log in console. However all my deployments weren't accessible including newly created one. So, as their system went down, you might have problems accessing your deployment. Even if error description is related to invalid subscription key, it might be that issue. It's a new service and I still see 500 Internal errors in console often. If issue is still reproducing, I recommend you to contact their support team crservice#microsoft.com. They are very helpful. However they respond during European working hours.
I have experienced similar issues when we hit the API limits. It would not be a bad idea to check if either the number of requests per second or the volume has been reached ( in case of bootstrap keys it is 1000 hits)