Multiple JsTestDriver clients send tests to one JsTestDriver server.

[GoogleCodeExporter]

As a Javascript Developer, I would like my tests to run against a common
remote JsTestDriver server connecting to a range of browsers and OS's. So
that my team and I are not required to each have copies of every browser
and OS on our developer machines.

NOTES:
I have done a few tests of running two concurrent test runs against a
common JsTestDriver server and achieved some interesting results. One test
suite with 5 tests being run against 4 browsers:

Total 25 tests (Passed: 25; Fails: 0; Errors: 0) (29.00 ms)
  Firefox 3.5.4 Linux: Run 5 tests (Passed: 5; Fails: 0; Errors 0) (8.00 ms)
  Safari 531.21.10 Mac OS: Run 10 tests (Passed: 10; Fails: 0; Errors 0)
(29.00 ms)
  Chrome 5.0.342.7 Mac OS: Run 5 tests (Passed: 5; Fails: 0; Errors 0)
(5.00 ms)
  Firefox 3.5.8 Mac OS: Run 5 tests (Passed: 5; Fails: 0; Errors 0) (10.00 ms)

These results make it look like the test suites are not running sandboxed
and are able to pollute each others environment.

A potential solution could be to spawn an iframe within the Remote Console
Runner and run the tests there. So each test suite gets its own iframe
sandbox to play with.

Original issue reported on code.google.com by akiel...@gmail.com on 27 Mar 2010 at 5:40

[GoogleCodeExporter]

I believe JsTD already supports the use case you want.  We are setup exactly as 
you have described above and it works great.  
Here is what we are doing:

We are running multiple instances of the JsTD server on our build machine.  So 
we have servers running on:
http://build:9000
http://build:9001
http://build:9002
...

We then have a machine that is dedicated to running the browsers for the 
servers.  Right now, it's a windows machine running 
Firefox.  Firefox is setup to open a tab for each server above when it is 
started. So we have a bunch of tabs:
http://build:9000/capture
http://build:9001/capture
http://build:9002/capture
...

Then, all that is needed is to adjust the server: setting in your config file, 
or specify it manually when running the tests using -
-server.

The way we are using this is that we have about 15  JsTD server instances.  We 
have 4 that are reserved for use by our Hudson 
build slaves.  The rest are used by developers, where each developer has his 
own JsTD server to test against.

Running in this mode, we typically need to restart the browser running all the 
tests about once a week.  Additionally, we need 
to restart the JsTD servers on the build machine occasionally.

Original comment by burke.we...@gmail.com on 23 Apr 2010 at 3:07

[GoogleCodeExporter]

This issue is a bit old. Any news on this, because we are facing exactly the 
same problem and are thinking more alternatives to the fact that the server 
cannot handle more than one concurrent client throwing tests requests at it...

Original comment by davidst@gmail.com on 29 Feb 2012 at 5:01

[GoogleCodeExporter]

It's supposed to queue multiple requests until the request is done. What's log 
look like?

Original comment by corbinrs...@gmail.com on 29 Feb 2012 at 5:06

[GoogleCodeExporter]

Will try to reproduce it again.

Anyway, looking at the code in FileSetGetHandler it looks like if the browser 
is in use, it simply returns that it failed to get a new session for the test:

  public void startSession(String id, PrintWriter writer) {
    logger.debug("trying to start session for {}", id);
    SlaveBrowser browser = capturedBrowsers.getBrowser(id);
    String sessionId = UUID.randomUUID().toString();
    SlaveBrowser slaveBrowser = capturedBrowsers.getBrowser(id);

    if (browser.tryLock(sessionId)) {
      logger.debug("got session lock {} for {}", sessionId, id);
      writer.write(sessionId);
      slaveBrowser.resetCommandQueue();
      slaveBrowser.clearResponseQueue();
      browser.heartBeatLock(sessionId);
    } else {
      logger.debug("checking session status for {}", id);
      // session is probably stalled
      if (!browser.inUse()) {
        logger.debug("forcing unlock for {}", id);
        browser.forceUnlock();

        slaveBrowser.resetCommandQueue();
        slaveBrowser.clearResponseQueue();
        writer.write(browser.tryLock(sessionId) ? sessionId : "FAILED");
      } else {
        logger.debug("session unvailable for {}", id);
        writer.write("FAILED");
      }
    }
    writer.flush();
  }

Original comment by davidst@gmail.com on 29 Feb 2012 at 5:35

[GoogleCodeExporter]

Half the story. See 
http://code.google.com/p/js-test-driver/source/browse/trunk/JsTestDriver/src/com
/google/jstestdriver/browser/BaseBrowserSessionManager.java

For the other half.

Original comment by corbinrs...@gmail.com on 29 Feb 2012 at 5:46

[GoogleCodeExporter]

although I'm now seeing the BrowserActionExecutorAction which is related to 
what you are saying, probably...

I'll get back to you when I can reproduce it again

Original comment by davidst@gmail.com on 29 Feb 2012 at 5:49

[GoogleCodeExporter]

Retrying with the very last version fixed the problem for me, thx!

Original comment by davidst@gmail.com on 1 Mar 2012 at 11:51