we are experiencing issues with CI where it fails with race: limit on
8128 simultaneously alive goroutines is exceeded, dying
this, despite the fact that closing the executor should clean up all
worker goroutines. Apparently in CircleCI runtime.NumCPU() reports 36,
so the goroutines added up quickly.
also fix a *bunch* of tests that weren't closing the clusters they
created. Cleaned up one test to use t.Run instead of just checking
everything in a loop
the buffers were unused internally and external users had no access to them.
Those wishing to read the logs of the cluster in tests may replace stdout/stderr
with buffers on the Command struct.
The race occurred when a node was stopped and then started again. some
memberlist goroutines might not be completely cleaned up by the time the node
restarted, and then two loggers were using the same output buffer.
cluster is in degraded state when some number of nodes greater than 0 but less
than replicaN have failed. This is sort of a hybrid of "STARTING" and "NORMAL"
states because we can still respond to queries as in the NORMAL state, but we
need to be alert to re-add nodes to the cluster if they come back online which
required some changes to the cluster logic.
In order to make debugging easier, the test.MustRunCluster functionality now
names the nodes in the cluster explicitly as "node0", "node1", etc. "node0" is
the coordinator.
A number of TODOs are left in the test for scenarios that need to be checked.
refactor handler Close func to use errgroup to be a bit less messy.
refactor pilosa.Server closing to actually return an underlying error if one occurs
add option to pilosa/test.Cluster and pilosa/server.Command to control close
timeout. currently is only used by the http handler, but conceivably could be
passed as a parameter to other subsystems of pilosa/server.Command
