tree f0047d1f7515a2c80665fedc10d708484a730c12
parent 100241c182e9af1f7fe05046c3f9e0e87c7b64e4
author Joan Touzet <wohali@atypical.net> 1473575080 -0400
committer Joan Touzet <wohali@atypical.net> 1473575080 -0400

Disable should_process_waiting_queue_as_fifo test

COUCHDB-3140

This PR disables the problematic queue-as-fifo test. As written, any
call in a test to spawn_client/1 returns immediately, and does not
guarantee that the call to couch_query_servers:get_ddoc_process/2
returns before control flow proceeds to the next line in the eunit test.
As it turns out, on Windows, the call to spawn_client for ddoc5 succeeds
prior to the ddoc4 call in this test, thus always failing.

Insertion of a timer:sleep/1 call between the spawn_client/1 calls seems
to solve the problem, but even this is "lucky" behaviour. Semantically
the way this test is written, with spawn_client/1 using spawn/1 to spin
off the actual get_ddoc_process/2 call, there is no guarantee that the
couch_proc_manager FIFO queue is being populated correctly.

Further, if the get_ddoc_process/2 call takes longer than the defined
timeout (5000 ms) this test will always fail, as no provision is made to
keep trying for an os_process after that time. Again we are "lucky" that
the test runs fast enough that this is not a problem, but relying on a
performant BEAM VM for test success in any regard is equally
problematic.

For this reason I am completely commenting out this test until the
harness can be fixed. I believe the impact to couchdb is minimal.

(It also suggests we may want to rethink how requests for os processes
are queued and issued at some point in the future; this approach seems
sub-optimal, especially if strict FIFO ordering is an expectation of the
system.)

/cc @eiri @rnewson @janl