I'm developing a packaged app and everytime I make a change that I want to test, I repackage the app and update it. This occurs fairly often but sporadically (between 10 seconds and 10 minutes depending on changes). But every now and again, Chrome suddenly decides I'm asking too often and throttles the app's update requests. After that, it will not update at all (I assume it's in a "timeout" but I have no idea how for how long).
How do I change the throttling threshold? How do I stop Chrome from throttling once it's done so?
Adding the flags at command line did not help: http://www.chromium.org/throttling
//This does not fix the problem
google-chrome --disable-extensions-http-throttling --disable-enforced-throttling
Throttling only occurs if a second update check is done within 5 seconds and the previous check did not find an update. The solution is to wait longer than 5 seconds between unsuccessful checks. (Thanks to RobW for this answer)
The 5 second rule, while undocumented (and unchangeable from a setting) is confirmed in the source code for Chrome(ium):
https://code.google.com/p/chromium/codesearch#chromium/src/chrome/browser/extensions/updater/extension_updater.cc&l=51
// Require at least 5 seconds between consecutive non-succesful extension update
// checks.
const int kMinUpdateThrottleTime = 5;
Related
This indicates that the script exceeded the total allowable execution time for one day. It most commonly occurs for scripts that run on a trigger, which have a lower daily limit than scripts executed manually. The limit as far as I am aware is 6 hours per day. None of my scripts run for that long.
Everything was fine earlier. Suddenly, over the last 3-4 days, all the scripts have started failing. I have no clue what's happening. My only hunch is that one of my scripts is going into an infinite loop. But still, if that happens, it will fail soon and collectively, all scripts would not run for 6 hours.
Please help to resolve this issue. I have a G suite id but Google mentioned that I get help at stackoverflow and that they cannot help.
The exception message should also tell you a lot about what is happening. If you are not sure which script is causing the issues you can try to go to the Google Apps Script Manager. In the menu bar on the left you will see a section called My Executions. If you click that you can see a list of scripts that ran and how long they ran for. This page also allows you to sort by duration and filter the results to hopefully help you figure out what is going on.
It possible that you have reached your quota. Having a Google Suite account allows you up to 6 hrs/day of Trigger Total Runtime. Also make sure you are not going over the limit on single script runtime as outlined here further down on the Quota For Google Services page.
For Google Suite Accounts the quota is:
Script runtime: 6 min/execution
Custom function runtime: 30 sec/execution
I had a similar problem. It's a little maddening because getting an error for the script leads one to believe it is a possible syntax problem. More likely, the script never ran in the first place, which is why you likely don't have a failed execution status for the trigger. What may have happened instead is that you have a script or scripts that are still firing for documents that no longer exist.
Navigate to "My Triggers" in the G Suite Developer Hub: https://script.google.com/home/triggers
Click on any time-based events and select "executions."
Search the "status" column for the words "Timed out," and check the duration.
Delete the trigger(s) that is timing out, or otherwise resolve why it is timing out (such as restoring the deleted document).
In my case, I had deleted several old spreadsheets, but one of my add-ons (Supermetrics) was still firing triggers. I had incorrectly assumed that when I deleted my spreadsheets the triggers would have gone with them. Instead they were firing and timing out after about six minutes, and then four hours later they would try to execute again. I added up the duration for all of these triggers and, sure enough, it exceeded my quota.
Delete those old triggers, and you'll likely be back within your quota limits the next day when it resets. This is what worked for me, but I imagine it's not a one-size fits all solution.
I just started using Selenium Grid.
The current problem I'm facing is when a test crashes. The browser stays open forever until I arrive and close it myself so the next set of tests can start.
I noticed that the NODE configuration has two timeout configurations, one for -timeout and another for -browserTimeout
For the -timeout, it says the browser will be "released" for another test. For -browserTimeout, it simply doesn't say anything.
I don't understand what it meant by "released".
What I need is the browser to be closed when the timeout happens.
What option will close the browser?
This documentation should help you out
Quoting the documentation
timeout 30 (300 is default) The timeout in seconds before the hub automatically releases a node that hasn't received any requests for more than the specified number of seconds. After this time, the node will be released for another test in the queue. This helps to clear client crashes without manual intervention. To remove the timeout completely, specify -timeout 0 and the hub will never release the node.
browserTimeout On the hub you can also set -browserTimeout 60 to make the maximum time a node is willing to hang inside the browser 60 seconds.
Here's my limited understanding
timeout - This value represents how long should the Grid wait before it treats a particular test session (a particular running test case) as stale, so that that particular test session can be cleaned up and the slot released so that some other test case can basically execute on the node. This parameter is relevant when lets say you are running a test case from within eclipse and you click on the RED button and end your test case abruptly. At that time the client (your test case) hasn't sent a "end-session" signal to the remote. So this session is stale and the grid has to clean up this orphan session.
browserTimeout - This value represents how long should the Grid wait before it treats a particular test session (a particular running test case) as stale, due to the browser getting hung (maybe due to a browser crash or due to a rogue javascript on the web application which has frozen the browser). Here the important thing to note is that the client (the test case running from within your IDE or a Continuous Integration tool such as Jenkins for e.g.,) is still active but its the browser that has got un-responsive.
So to safe guard your executions from orphaned test sessions due to client crashes use timeout and use browserTimeout to safe guard your grid from frozen browsers which refuses to return back and causes stalled test executions.
I've got a windows store app, and I'm setting it up to periodically update the tile. Originally, I set it to use StartPeriodicUpdate(Uri, PeriodicUpdateRecurrence) but it didn't seem to be updating, and because the minimum recurrence is HalfHour, I wanted to use StartPeriodicUpdate(Uri, DateTime, PeriodicUpdateRecurrence), and set the startTime to DateTimeOffset.Now.AddMinutes(5) so that it would wait 5 minutes before updating, to make testing easier. Code:
public void UpdateLiveTile()
{
LiveTileUpdater.Clear();
var uri = TILE_UPDATE_URI; // example
var start = DateTimeOffset.Now.AddMinutes(5);
LiveTileUpdater.StartPeriodicUpdate(uri, start, PeriodicUpdateRecurrence.HalfHour);
}
However, when I run this, the tile updates immediately, instead of updating 5 minutes from when it's called. I would think that calling the override without the startDate parameter would run immediately (it does) and then the other would run after 5 minutes. Does anyone know why it updates right away, or how I can make sure it's delayed?
Edit: Additionally, if anyone knows why the periodic update isn't occurring either, that would be a great help. The server is definitely responding correctly, because the first update works great, but it never changes. Documentation indicates that the start time and periodic interval could both be delayed by up to 15 minutes, but it's way beyond that margin of error, and I'm not getting any updates.
I found the answer on this page (bold is my emphasis):
When you call one of those methods, the URI specified in the call is immediately polled and the tile or badge is updated with the received contents. After this initial poll, Windows continues to provide updates at the requested interval. Polling continues until you explicitly stop it...
I think the reason that the 5 minute refresh wasn't working, then, is that it polls immediately, and then won't poll again sooner than the interval (30 Minutes), but that it would refresh 30 minutes from then instead of now. This last part is speculation, but the above paragraph indicates why it was updating immediately.
For the second part, it looks like it was updating (when I ran on localhost with a breakpoint, the breakpoint was eventually hit and it refreshed the tile), I guess I just didn't wait long enough.
Is there anyway of catching this GAS error: "Exceeded maximum execution time"
I mean catching with try ... catch(e) // so far it's not working for me.
Thanks
As written in the comments to your question, thats not possible. But, however, you can set a flag in scriptDB or properties when execution starts and clear that flag when execution comes to a normal end, so you can find out during the next run wether your script came to a regular end when it was run last time and try to take corrective actions if not.
The answer above is correct; it's not possible. An easy alternative to the workaround that pbhd mentioned would be to simply track the runtime of your script (e.g. comparing results of new Date().getTime() at regular intervals) and run whatever you'd include under your catch statement right before you hit the maximum execution time. The maximum is 6 minutes (reference).
That way, you don't have to catch the error -- you can preempt it.
During normal testing, it is possible to accidentally create an infinite (or very long running) loop that consumes the daily execution time limit 100%.
Even if you realize what you have dome wrong immediately, you cannot immediately re-try with Google scripts for another 24 hours - thus slowing down ongoing development significantly and maybe forcing the developer to do some other work , taking his focus/"attention stream" away from the current problem. This is almost always bad.
My product ("IBM OLIVER CICS test/debug" - see Wikipedia article) solved this problem - and many others - around 37 years ago - by having a time limit on any particular transaction and intercepting the resulting time out, allowing options of:-
continuation or
examine/modify variables
"manual" re-try (for the same time) or
abort.
Google could implement this approach just as easily - by "pausing" if execution time is looking too heavy. I had a similar solution to other resources in OLIVER - such as excessive API calls ("possible macro loop") and excessive memory usage.
It seems it takes an "old timer" like me to provide solutions to problems that have existed "since the beginning of time" (and certainly before PC's were thought of).
Googles current "solution" (i.e. absolute limits) only helps Google keep its own servers from being swamped. It would be easy for them to do what OLIVER did all those years ago. By the way there should be no "IBM" prefix on the Wikipedia article - it was my own product and some clown Wikipedia editor altered it to include the prefix.
(By the way, Google do not prevent other scripts on same s/s running - that maybe only use minimal amounts of extra time ( i.e. Scripts on the same spreadsheet still work) . I tried renaming the original script as an experiment but it was stopped after a very short time with "exceeded execution time" error.
GIZ-A-JOB Google - you know its worth it!
I'm writing an application which pulls up to several dozen images from a server using Loader objects. It works fine in all browsers except Firefox, where I'm finding that, with over 6 or so connections, some simply never load - and I cease to get progress events (and can detect no errors/error events)
I extended the Loader class so that it will kill and reopen the transfer if it takes longer than ten seconds, but this temporary hack has created a new problem, in that when there are quite a few connections open, many of them will load 90-odd percent of the image, get killed for exceeding the time limit, open again, load 90-odd percent etc...until the traffic is low enough for it to actually complete. This means I'm getting transfers of many times the amount of data that is actually being requested!
It doesn't happen in any other browser (I was anticipating IE errors, so for Firefox to be the anomaly was unexpected!), I can write a class to manage Loaders, but wondered if anyone else had seen this problem?
Thanks in advance for any help!
Maybe try to limit number of concurrent connections.
Instead of loading all assets at once (then FP or browser manages the connections) try to build a queue.
Building a simple queue is fairly easy - just create an array of URLs and shift or pop a value every time loader has finished loading previous asset.
You might use an existing loader manager like LoaderMax or BulkLoader - they allow to create a queue, limit number of connections and are fairly robust. LoaderMax is my favourite.