We have an excessively complex stored procedure in SQL Server (which I did not write and cannot change).
I created an Azure logic app, using a "Recurrence" (not a "Sliding Window") trigger, with an "Execute stored procedure (V2)" action, and set the "frequency" to run daily at 22:00 (10pm).
But, I try running it manually just to test it (Run Trigger).
It runs for between 9 1/2 and 10 1/2 minutes, then fails with a "Bad Gateway" and "Error 504" and "Timeout Expired" error (see JSON at bottom):
How do I increase the timeout? Is there a simple setting buried in Azure that I'm missing?
I never specified any gateway, and another, much simpler stored procedure with no gateway specification executed fine.
And lastly, I am an Azure neophyte.
Thank you.
{
"error": {
"code": 504,
"source": "logic-apis-eastus2.azure-apim.net",
"clientRequestId": "{I removed the client request Id before posting this}",
"message": "BadGateway",
"innerError": {
"status": 504,
"message": "Execution Timeout Expired. The timeout period elapsed prior to completion of the operation or the server is not responding.\r\nclientRequestId: {I removed the client request Id before posting this}",
"error": {
"message": "Execution Timeout Expired. The timeout period elapsed prior to completion of the operation or the server is not responding."
},
"source": "sql-eus2.azconn-eus2.p.azurewebsites.net"
}
}
Related
I am using a custom application that uses the Microsoft Graph REST interface.
Through this REST interface I regularly request changed dates using DeltaQuerys.
I have the problem that with some users, the DeltaQuery REST requests always result in an HTTP 503 or 504 error response.
This does not change even if the queries are repeated after waiting for some time or even in the next few days.
The error also occurs if the DeltaQuery query is executed without DeltaToken or SkipToken, it then comes back on the same result page.
Changed appointments can only be queried again after certain mostly daily long-running appointment series with many exception appointments has been deleted.
I do not know what to change in the query.
There is no way to tell which appointment series are causing the problem and need to be deleted.
The last query with this error was this one:
2021-03-23 13:42:03,391 Request: GET https://graph.microsoft.com/v1.0/Users('...')/calendarview/delta?%24skipToken=aVxnGmD_iauljNDUWJs5WrXLyr_lwnfNiDvP-lcTAFa_UvBvr8wWslITny9WhaMfWACh0-OAnbh3WthBwHwGzHhAIo5vQfyuzaNTzlG4YdIcistSWcGnd_k4woip1k6Lm7IaHAJSYKzh0Sv5R6nBLUNTldsS_Pf7n2yvldImrFNYctGchB7319D8wCbG7MJTp3frgANJ0IesjZemQQq2UYb1x8ZJj7ch9r1SxTURZY3c-yFftH93NMwXTPyjuk0d.DjcXPsqmTgRw_0ygOoRjf891oiOX87OU4iOLpFD_eoc
Response: HTTP 503 (duration: 23907ms)
{
"error": {
"code": "UnknownError",
"message": "",
"innerError": {
"date": "2021-03-23T12:42:03",
"request-id": "64b1743b-69c4-4602-a282-fd632f256e02",
"client-request-id": "4f7f37be-ad58-4f75-bc70-16228360b5eb"
}
}
}
With kind regards,
Demian
I have two policies in a main package which call the same instance (the locally running OPA server) like this:
package main
get[response] {
response := http.send({
"method" : "GET",
"url": "http://localhost:8181/v1/data/example"
})
}
put[response] {
response := http.send({
"method" : "PUT",
"url": "http://localhost:8181/v1/data/example",
"body": { "example": true }
})
}
I run my OPA server like this:
opa run -w -s main.rego --log-level debug --log-format text
When I curl the get policy I get a 200 response:
$ curl -X POST localhost:8181/v0/data/main/get
[{"body":{},"raw_body":"{}","status":"200 OK","status_code":200}]
However, when I curl the put policy it times out after 5 seconds:
$ curl -X POST localhost:8181/v0/data/main/put
{
"code": "internal_error",
"message": "error(s) occurred while evaluating query",
"errors": [
{
"code": "eval_builtin_error",
"message": "http.send: Put http://localhost:8181/v1/data/example: net/http: request canceled (Client.Timeout exceeded while awaiting headers)",
"location": {
"file": "main.rego",
"row": 11,
"col": 14
}
}
]
}
Does anyone know why this might be happening for PUT and not GET requests against the OPA instance?
Meanwhile a comparable curl works fine:
curl -X PUT -d "{}" http://localhost:8181/v1/data/example
I'm aware this is a strange/bad 'use case' but I'm asking out of curiosity in an attempt to better understand what's going on in the rego http functionality.
OPA currently supports multiple concurrent read transactions (e.g., policy queries) and one concurrent write transaction (e.g., updating data). However, when the write transaction commits, OPA waits until readers have finished.
Since you are executing a write operation from inside a policy query, the commit for the write operation blocks. This is why you see the timeout w/ the put rule. You do not see a timeout with the get rule because there are no write transactions (so nothing blocks.)
This is an implementation detail of OPA. In theory OPA could support multiple concurrent readers and writers and in that case you could modify data from inside a policy query. It's just not a high-priority feature.
That said, we do not recommend doing this.
For our internal application we synchronize our user's calendars (in our Office 365 tenant) with a local "cache" in our database. We're using the new Delta Queries in Microsoft Graph to do track these changes.
Most of the calendars synchronize correctly, but for some reason there is one single calendar where we consistently hit a 504 Gateway Timeout error when attempting to request the events using the nextLink received from the first request.
First request:
GET https://graph.microsoft.com/v1.0/users/<userId>/calendars/<calendarId>/calendarView/delta?startDateTime=2017-06-10t00%3A00%3A00Z&endDateTime=2018-06-10t00%3A00%3A00Z
First response:
{
"#odata.context": "https://graph.microsoft.com/v1.0/$metadata#Collection(event)",
"#odata.nextLink": "https://graph.microsoft.com/v1.0/users/<userId>/calendars/<calendarId>/calendarView/delta?$skiptoken=R0usmcdvmMuZCBYV0hguCGmIJqcU0n_6jVFWUlNKbXkBKYVlxLSMsISZI5sLLLJyLJF8hZIj0PURpAeP_XxydW_qbMUoFMTXjOpLa8Ta6rxMRA7Wv6IHYfjyLPcDzCbM_hKvTgq8BZaBeJv-a61mebF6X2wT4HqCAGL5lL4nLZabHk1nD9GbWJ0a4Qq0M41_GPYxEi5YNe9u1673SQ1Djw.F85xXB6GjtO7myCQCOgFvzp1G7mQB0BvuHQJyn0CICQ",
"value": [
<list of events>
]
}
Second request:
GET https://graph.microsoft.com/v1.0/users/<userId>/calendars/<calendarId>/calendarView/delta?$skiptoken=R0usmcdvmMuZCBYV0hguCGmIJqcU0n_6jVFWUlNKbXkBKYVlxLSMsISZI5sLLLJyLJF8hZIj0PURpAeP_XxydW_qbMUoFMTXjOpLa8Ta6rxMRA7Wv6IHYfjyLPcDzCbM_hKvTgq8BZaBeJv-a61mebF6X2wT4HqCAGL5lL4nLZabHk1nD9GbWJ0a4Qq0M41_GPYxEi5YNe9u1673SQ1Djw.F85xXB6GjtO7myCQCOgFvzp1G7mQB0BvuHQJyn0CICQ
Second response:
504 Gateway Timeout
{
"error": {
"code": "UnknownError",
"message": "",
"innerError": {
"request-id": "0784cffb-cba7-424b-be1d-74b2bfef5da1",
"date": "2017-07-10T09:11:33"
}
}
}
I've tried executing the script a few times over the last week, but the request consistently fails when using requesting the second page. Other calendars synchronize with no issues, so I don't really know how to debug these kind of issues. Is there anything we can do to resolve this issue?
I'm working with the team that owns Calendar sync to check where the latency in the stack is causing this time out. I'll post as soon as they have root caused this. I may need more info on what is special about this one Calendar encountering this issue.
Thanks,
Sri
I'm using the google safebrowsing api for getting fullhashes for the prefixes of hashes of url present in threat lists. When i'm using 5 threads to do the job, the job completes but the latency is high, so i tried increasing the threads to 7 and more but i'm getting the following error on doing that:
com.google.api.client.googleapis.json.GoogleJsonResponseException: 504 Gateway Time-out
{
"code" : 504,
"errors" : [ {
"domain" : "global",
"message" : "Deadline expired before operation could complete.",
"reason" : "backendError"
} ],
"message" : "Deadline expired before operation could complete.",
"status" : "DEADLINE_EXCEEDED"
}
But, I'm sure that my daily quota has not exceeded.
By looking at the console, i can see that the number of requests per second is not more than the default quota (3000 req/100sec).
What other reason can be there for the above error ?
I'm sending messages using the Microsoft Graph REST API. My application is a service/daemon application where I am sending email on a users behalf. I am using the sendMail API (POST /users/{user id}/sendMail ) and this works a very large percentage of the time. The problem is that every so often the following error is returned:
{ "error": { "code": "UnknownError", "message": "", "innerError": { "request-id": "a901d503-8acf-47e7-8f7e-a20311aa0e3b", "date": "2017-01-10T15:06:48" } }}
Any idea what is causing this error and is there a workaround?
The logs show that you're getting a 429 status code (which means throttling).
Is your app sending many requests for the same resource/user? If so, the error docs say this:
Client application has been throttled and should not attempt to repeat the request until an amount of time has elapsed.