Based on the warning provided, I expected browsers to drop context's in the order they were created.
However I did a test in Chrome where I create 16 contexts asynchronously (delay 200 ms between their creation). The first 10 are constantly redrawing something, while the last 6 make 1 draw call and then stop.
When I created the 17th context (this is when the error starts generating) all 10 of the 'constantly updating' contexts continued drawing. However when I tried to draw on the 6 'paused' contexts, it seems 1 of them failed to make any further draw calls.
From the best I can tell the context I couldn't get working again is the one that dropped, despite being created at a later date.
Is this expected behavior, or how do browsers decide which context to terminate?
There's no official spec regarding the order in which contexts should be dropped, developers are expected to bind to the webglcontexlost event and / or check the result of gl.isContextLost().
Related
I'm looking for the general algorithm/checks that Chromium does when you specify failIfMajorPerformanceCaveat to be true when creating a WebGL context on a canvas.
I searched the Chromium source code, but quickly got lost in the sea of results and interfaces. I can get it to fail to create a WebGL context if I specify this flag as true and I have hardware acceleration disabled, so I know hardware acceleration enabled/disabled is part of the calculation - but is there more to it than that?
I only care about Chrome/Chromium on any reasonably modern version.
The only two references I could dig up are in /gpu/command_buffer/service/gles2_cmd_decoder.cc and in /gpu/command_buffer/service/gles2_cmd_decoder_passthrough.cc, and both are just basically
if (fail_if_major_perf_caveat && is_swiftshader_for_webgl) {
// fail
}
where SwiftShader is the software rendering engine used for 3D graphics.
This flag was added back in 2013, with the commit message saying
Currently only fails if using swiftshader.
and quick looking at other issues related to this flag I couldn't find something that would add more feature to it, so I doubt there is anything else hidden.
So this will fail only if the software render is active, which should happen only where HWA is disabled (or unavailable).
Note that at the time of implementation they discussed the possibility to make it smarter and fail only if SwiftShader would actually be slower than the native GL implementation, which isn't always the case. But once again it seems they never got back to it.
Cannot find a clean way to set Stackdriver alert notifications on errors in cloud functions
I am using a cloud function to process data to cloud data store. There are 2 types of errors that I want to be alerted on:
Technical exceptions which might cause function to 'crash'
Custom errors that we are logging from the cloud function
I have done the below,
Created a log metric searching for specific errors (although this will not work for 'crash' as the error message can be different each time)
Created an alert for this metric in Stackdriver monitoring with parameters as in below code section
This is done as per the answer to the question,
how to create alert per error in stackdriver
For the first trigger of the condition I receive an email. However, on subsequent triggers lets say on the next day, I don't. Also the incident is in 'opened' state.
Resource type: cloud function
Metric:from point 2 above
Aggregation: Aligner: count, Reducer: None, Alignment period: 1m
Configuration: Condition triggers if: Any time series violates, Condition:
is above, Threshold: 0.001, For: 1 min
So I have 3 questions,
Is this the right way to do to satisfy my requirement of creating alerts?
How can I still receive alert notifications for subsequent errors?
How to set the incident to 'resolved' either automatically/ manually?
I was having a similar problem and managed to at least get a mail every time. The "trick" seems to be to use sum instead of count in combination with for most recent value - see the screenshot below.
This causes Stackdriver to send a mail everytime a matching log entry is found and closing the issue a minute later.
Normally, alerts resolve themselves once the alerting policy stops firing. The problem you're having with your alerts not resolving is because your metric only writes non-zero points - if there are no errors, it doesn't write zero. That means that the policy never gets an unambiguous signal that everything is fine, so the alerts just sit there (they'll automatically close after 7 days, but I imagine that's not all that useful for you).
This is a common problem and it's a tricky one to solve. One possibility is to write your policy as a ratio of errors to something non-zero, like request count. As long as the request count is non-zero, the ratio will compute zero if there are no errors, and so an alert on the ratio will automatically resolve. You need to be a bit careful about rounding errors, though - if your request count is high enough, you might potentially miss a single error because the ratio could round to zero.
Aaron Sher, Stackdriver engineer
We got around this issue by having the insertId as a label of the log-based metric we created for every log record we get from the pods running our services.
In the alerting policy, this label helped in two things:
We grouped by it (named as record_id) which served in making each incident unique, so it got reported without waiting for other incidents to get resolved and at the same time it got resolved instantly.
We used it in the documentation of the notification to include a direct link to the issue (log record) itself which was a nice and essential feature to have. https://console.cloud.google.com/logs/viewer?project=MY_PROJECT&advancedFilter=insertId%3D%22${metric.label.record_id}%22
As #Aaron Sher mentioned in his answer, it is a tricky problem. We might have done something not recommended or not efficient, but it works fine and of course we are open for improvement recommendations.
While performing loadtests on WSO2 BPS 3.2.0 we`ve ran onto the problem.
Let me tell you more about out project and our actions.
Our BPS process is designed to manage some interactions with 3 systems. Basically it is "spread" on two parts - first one to CREATE INSTANCE in one of systems, then waiting a bit, and then SELECT OFFER in instance context.
In real life it looks like: user wants to get a product, the application asks system for an offers and then the user selects offer from available ones.
IN BPS the first part is a straight-forward process, the second part is spread on two flows - one to refresh information with a new offers, and another is to wait if the user chooses one of them.
Our aim is to stand about 1000-1500 simulatious threads on the load-test. An external systems are simulated by mockups executed by LoadUI.
We can achieve our goal if we disable "Process-Level Monitoring Events" in deployment descriptor (set it to "none") of our process. Everything goes well and smooth for hours.
But if we enable this feature (and we need to), everything falls with an error very soon (on about 100-200 run):
[2015-07-28 17:47:02,573] ERROR {org.wso2.carbon.bpel.core.ode.integration.BPELProcessProxy} - Error processing response for MEX null
java.lang.NullPointerException
at org.wso2.carbon.bpel.core.ode.integration.BPELProcessProxy.onResponse(BPELProcessProxy.java:402)
at org.wso2.carbon.bpel.core.ode.integration.BPELProcessProxy.onAxisServiceInvoke(BPELProcessProxy.java:187)
at
[....Et cetera....]
After the first appearance of this error another one type appears - other threads just fall after the timeout.
It seems that database is ok (by the way, it is MySQL 5.6.25). The dashboard shows no extreme levels of input or output.
So I think the BPS itself makes a bottleneck. We have gave it 8gb heap and its conf options are set for extreme amounts of threads (if it possible negative values are set and if not - just ridiculously big like 100000).
Anyone has ever faced this problem? Appreciate any help very much.
Solved in BPS 3.5.0 version, refer to release-notes
I receive a Chrome (43.0.2357.124) "Aw, snap!" error that renders "Inspected target disconnected. Once it reloads we will attach to it automatically." in the developer console.
Without being too specific to my project and trying to make the question more generally applicable, it appears to occur occur during a Promise that features a ~5 second delay.
This function (can be seen in context on the repo https://github.com/mitTransportAnalyst/CoAXs/blob/master/public/scripts/main/services/analystService.js#L35-L44) performs fine on Firefox 38.0.5. It is receiving a large GeoJSON array - perhaps that could somehow be related to the issue, though I do not know for sure.
At this point, any advice on next steps for how to debug this would be appreciated, even googling this specific issue doesn't come up with any results (5 irrelevant results as of Wed 6:00, June 17: https://www.google.com/search?sclient=psy-ab&biw=1280&bih=678&q=%22inspected%20target%20disconnected%22%20chrome&oq=%22inspected%20target%20disconnected%22%20chrome&gs_l=serp.3...805885.806603.1.806844.2.2.0.0.0.0.72.122.2.2.0....0...1c.1.64.serp..2.0.0.O7y1WqVbj0c&pbx=1&psj=1&ion=1&cad=cbv&sei=LvKBVfarHcyw-AHVioHYBg&rct=j#q=%22Inspected+target+disconnected%22+chrome).
Added this as a comment but interested to see if anyone knows why this happened:
Issue ended up being related to the delayed receipt of > 3 MB files (assembled piecemeal). There is some (limited) documentation of this error occurring here code.google.com/p/v8/issues/detail?id=3968 (the results of which are, unfortunately, inconclusive). Ended up working with the data provider and reducing file size substantially, which resolved the issue. Curiously - if anyone can posit as to why this was occurring - console.loging where data was concatenated seemed to avoid the issue. If this didn't occur, the tab would suddenly exceed ~1.3GB and crash.
You can see link to point where I was console.loging here: https://github.com/mitTransportAnalyst/CoAXs/blob/master/public/scripts/analyst.js#L10343
Turn off your extensions. I had a Knockoutjs context debugger plugin and it caused the very same behaviour with the same version of Chrome.
I just have the same problem. When i check code that have a infinity loop. That is add the same object again and again it takes high memory. When it full the ram then the page is going to unresponsive. When i check it in Mozilla Firefox the ram full alert is shown in my Antivirus. Chrome can handle it but Mozilla can't take it. It will loop as it's possible. So don't blame chrome it is handle the exception. Check the codes. If its not your page then leave it.
Finally check the loops....
From what I understand, the big benefit of HTML5's shared web workers is that they can accept multiple connections in a single separate thread of execution.
My question is: has anyone gotten multiple connections with a SharedWorker to work as a single thread with Google Chrome? I'm using latest version 12.0.742.112.
Demo: http://demos.zulius.com/html5/sharedworker
Source (in case demo is down): index.html, sharedworker.js
The demo establishes 2 separate event listeners. The expected output is:
foo got message: Hello World! You are connection #1
bar got message: Hello World! You are connection #2
In the demo, both event listeners fire correctly, but the connection count variable is not maintained in the SharedWorker script. This leads me to believe each connection to the SharedWorker is executing in a separate thread.
Am I doing something wrong? Or is Chrome support for SharedWorker not quite there?
UPDATE: the demo works now.
You have 2 listeners to the Worker but you only start the Worker for once, so it's 1 Worker shared by 1 owner instead of 2 owners. Increasing the number of listeners doesn't affect the ownership.
You can see the example here:
http://weblog.bocoup.com/javascript-web-workers-chrome-5-supports-new-sharedworker
It has 2 frames, one containing the iframe and one inside the iframe. They both call the start method of the Worker so it's shared by 2 owners. Since the start method is called twice, the onconnect event should be fired twice, thus making connection.count equal 2.
In shared webworkers the context is alive till the last browser session end. shared webworkers can maintain the context around the browser tabs. They respond to the requests with the same context of data.
The change in context of data will affect all connections, the possibilities are you can update all the connections with single context change, you can maintain the data till the last connection end. you can maintain the connection changes in all views.
Here is a demo of Shared web workers with multiple connections.
http://www.antkorp.in/sharedworkers/