Bug 64490 - NRWT spins the HTTP server down and back up an extra time when retrying a failed HTTP test when
Summary: NRWT spins the HTTP server down and back up an extra time when retrying a fai...
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Tools / Tests (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Eric Seidel (no email)
URL:
Keywords: NRWT
Depends on:
Blocks: 64491
  Show dependency treegraph
 
Reported: 2011-07-13 15:51 PDT by WebKit Review Bot
Modified: 2012-08-08 16:51 PDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description WebKit Review Bot 2011-07-13 15:51:58 PDT
NRWT spins the HTTP server down and back up an extra time when retrying a failed HTTP test when
Requested by abarth on #webkit.
Comment 1 Dirk Pranke 2011-07-13 15:55:06 PDT
I'm not sure if you can do anything about this and still drop the http lock aggressively (in order to enable concurrent NRWT runs to share the http lock).

Two possible options are to not drop the lock if there is a failure (assume that retrying the test takes precedence over sharing the machine), or to provide a command line flag to toggle whether we need locks at all (and just start and stop the server at the beginning/end if you don't).

But starting and stopping should be pretty fast ... is this causing some other problem, or is it just slow?
Comment 2 Adam Barth 2011-07-13 16:00:39 PDT
I suspect an easy solution is to just keep holding the lock when all the tests we've been asked to run are HTTP tests.  That case will basically only occur when running NRWT interactively and when the user has selected a small subset of tests to run.
Comment 3 Dirk Pranke 2012-08-08 16:51:28 PDT
at least now (and I think this was probably the case even when this bug was filed), the code that manages retrying on failures is separate from the code that actually starts and stops the servers (manager.py vs. layout_test_runner.py).

So, we'd have to rework the layering to add a dont_stop_the_server_if_there_are_failures and then a _no_need_to_start_the_server_its_already_running flag on those interfaces. 

This doesn't really seem worth it to me, but I'm not sure if this is really annoying anyone else?

Thoughts?