64490 2011-07-13 15:51:58 -0700 NRWT spins the HTTP server down and back up an extra time when retrying a failed HTTP test when 2012-08-08 16:51:28 -0700 1 1 1 Unclassified WebKit Tools / Tests 528+ (Nightly build) Unspecified Unspecified NEW NRWT P2 Normal --- 64491 1 webkit.review.bot eric abarth dpranke oldest_to_newest 436723 0 webkit.review.bot 2011-07-13 15:51:58 -0700 NRWT spins the HTTP server down and back up an extra time when retrying a failed HTTP test when Requested by abarth on #webkit. 436728 1 dpranke 2011-07-13 15:55:06 -0700 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? 436735 2 abarth 2011-07-13 16:00:39 -0700 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. 690928 3 dpranke 2012-08-08 16:51:28 -0700 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?