We are using the google-api-client gem in our Ruby on Rails project to access the Google Drive API methods and everything has been working great. However, we are sometimes receiving the following error response from the API when calling the drive.files.update or drive.files.insert methods:
{"code"=>500, "message"=>"Unable to read application configuration information"}
This error is not documented in the list of possible errors from the SDK, so I am not sure how I should go about it. Could you please help?
Thank you!
If this error is transient, the best way is to have a retry strategy when that happens (simply retry the request 2 or 3 times before giving up).
It seems like some concurrency issue on the Drive side where a request to read your application's configuration times out. By experience with Google APIs - and web APIs in general - I can tell you that, even though the team will try to fix/improve these (btw I will repport the bug so they can investigate) errors like that will always happen once in a while even with a very low occurrence as concurrency, timeout and reliability issues on distributed, web-scale systems are extremely hard to resolve. The best to have fail-proof code on your side is to retry a few times on every single 500 and 503 errors from external web APIs.
If you really have time on your hands you could even implement an exponential backoff strategy where the time between each of your retries increases each time as described in our documentation.
Related
I have been looking everywhere for a solution to this problem.
At my work, we are trying to integrate Maximo with another system via the other systems REST API (which returns JSON responses). I am able to make this integration work on a small scale, however this API is taking upwards of 5 seconds to respond per request. Currently, I have defined this system as a JSON Resource, and I copy daily "snapshots" of the non-persistent data to a persistent attribute using an automation script. The requests all run in a sequence - which works slowly for 5 assets in testing, and will definitely not scale to 1000's of calls a day.
Assume that the API of the external system cannot be modified in any way... Is there a way to query this API in a non-blocking way? I'd imagine that if I could send a request, and send the next, etc. without needing to wait for a reply to proceed, this would solve the problem.
I looked into Invocation and Publishing Channels, and also Enterprise Services, and it seems like Enterprise Services along with JMS Queues might be what I need, however documentation says that these only support queuing incoming data... and I can't see how this solves my problem.
Any help? I am completely stuck on this.
Thank you!
I had to do something that sounds similar, once. I tried JSON Resources, but they didn't work for me. I ended up using the examples in Maximo 7.6 Scripting Features to do it. The first code sample in that document is a library script for making HTTP/S calls using out-of-the-Maximo-box libraries, and other examples in that document use IBM's JSONObject and JSONArray classes (also available out of the Maximo box) to parse responses.
To get things going concurrently / multithreaded, you could configure a cron task to call your automation script, and configure multiple instances on various schedules to call the same one and use the args or some other mechanism to prevent collisions.
I'm using google mymaps. I have about 10 layers which represent about 12000 features.
Google says it can handle 10 layers and about 20000 features...
Sometimes the map is displaying or I'm getting this error:
503. That’s an error.
There was an error. Please try again later. That’s all we know.
Also, the navigation is very slow on Google Chrome compare to Internet explorer.
Anyways to fix this bug and issues?
503 means server error on Googles side.
10.5.4 503 Service Unavailable The server is currently unable to handle the request due to a temporary overloading or maintenance of
the server. The implication is that this is a temporary condition
which will be alleviated after some delay. If known, the length of the
delay MAY be indicated in a Retry-After header. If no Retry-After is
given, the client SHOULD handle the response as it would for a 500
response.
it could be your input is too difficult for the server to perform, and it crashes. You could try to reduce the complexity of your requests, or perhaps reduce the frequency of which you send the server a request.
I failed to start my instance (through the web browser), it gave me the error:
"The zone 'projects/XXXXX/zones/us-central1-f' does not have enough resources available to fulfill the request. Try a different zone, or try again later."
Can anyone suggest some resolution to it.
The share error message meaning that you’re having a temporary resource stock-out issue in that particular zone. I would like to point you to this post made by "Paul Nash" on 4/18/17, who thoroughly explained the resource stock-out issue at Google Cloud Platform (GCP).
As a workaround, I would recommend that you try a different zone or to try later if you are looking to get resources in the same zone as those issues are to be expected transiently.
We also recommend deploying and balancing your workload across multiple zones or regions to reduce the likelihood of an outage. For more details visit the following link. Please review the documentation which outlines how to build resilient and scalable architectures on Google Cloud Platform.
Again, we want to offer our sincerest apologies. We are working hard to resolve this and make this an exceptionally rare event.
Im getting inconsistent behaviours when sending POST requests to a google apps script deployed as webapp.
I have a desktop app sending POST calls to a GAS webapp. This calls may be totally variable in their cadence, from 1 in several minutes, to bursts of dozens per second.
In my tests I have found requests seemingly lost, requests that don't progress along the webapp internal logic flow (like script instances that get cut or interrupeted (?)), while others work flawlessly. There is no evident pattern.
However, trying things around, I found that if I space the calls, adding a pause between requests, everything normalizes.
Are there stablished and known limits for this? The only option I have to solve this is to introduce this artificial intervals between calls? I have not found information on this in the GAS quotas page.
Any help and ideas would be appreciated.
Confirming in the answer: there is no evident or documented per-minute limit on the number of requests to a GAS webapp.
The issue I'm experimenting is related to concurrency. Even when they are coming from the same source, fast paced requests can produce concurrency issues when accesing storage services like Cache or Properties.
This should be handled using the Lock Service.
I am searching for a nice way how to close an WinRT app after fatal error.
This should be used only in last chance error handlers TaskScheduler.UnobserveTaskExcption and App.UnhandledException where I obviously failed to handle it correctly on right places. Should never happen, but...
Desired behaviour: Application should then show 'Sorry' message, log the exception and after user clicks Ok button, app should be closed.
I searched for solutions and lot of results points me, that WinRT must not be closed programmatically. Eg. here programatically close win8 app .
When I call Exit method, app is closed, but afterwards exceptions are thrown, like could not do this and that because app is closing...etc.. Makes me kind of nervous.
How would you solve my problem? It has no sence to keep the app running after unhandled exception, and let it crash by setting Handled = false is not good solution as well I thing. Beside this UnobservedExceptions does not trigger crash. I heard that apps with crashes will be removed from store.
Thx for your ideas!
Referring to the application lifecycle provided by Microsoft, the app should terminate without any warning and return the user to the Start screen.
http://msdn.microsoft.com/en-us/library/windows/apps/hh464925.aspx#app_crash
You should not be closing apps which target the Windows Runtime at all. The app lifecycle management system built-in takes into account many factors including usage statistics and current system resources and will almost certainly make better decisions about when to close apps than you will.