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.
Related
We use Netty, version 4.1.13. We create HttpServer, HttpServerInitializer, HttpServerHandler and start it through using a port.When we make a request from Chrome Browser, HttpServerInitializer is called 3 or 4 times (sometimes 3, sometimes 4) and it is called again after 10 seconds.When we make a request through Microsoft Edge or through console, it is called one times as expected and HttpServerHandler handles the rest.
What should we do to prevent HttpServerInitializer's handling unnecessary extra requests.We have session operations attached to pipeline on Initializer, so this is a critical issue for us.
The default behaviour of browsers for HTTP 1 is to open several connections (how many depends on the browser) to do requests in parallel. Like that, they can retrieve resources like css, js, images,... in parallel.
The number of connection is configurable into the browser. In general there are two preferences: the maximum number of connections by hostname and the total maximum number of opened connections.
See also: http://www.browserscope.org/?category=network&v=0
So, when you start a request with Chrome, it opens several connections, even if it use only one if there is not so much request done. The idle an unused connections will be closed after some seconds.
I think that's why you see the HttpServerInitializer being called several times, only because there are several connections. So, server side, it's normal, because you don't know if it's different clients or only one with many connections.
I advice you to not do costly operation on Connection Opened event, but only when you receive a valid message/request. Your initializer should only configure the necessary handlers on the pipeline which should be quick and simple, and nothing else.
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'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;
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.
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/