Filter expected log output by default, unless a flag is provided, or a
test fails.
This makes it possible to see unexpected things. Having noisy tests
makes it too easy to miss actual problems.
It wasn't closing the recvBuffer body in all cases during shutdown.
This change also:
* adds a new test with concurrent streams doing their own serial sends.
This test was part of earlier debugging, but exists now to add more
test coverage around concurrency.
* starts a cleanup of the end2end testing code, to be continued later.
but the cleanup was necessary when writing the new test to be clean
and not add more positional parameters.
* documents the concurrency expectations of the ServerTransport
interface, cleaning up some other nearby documentation in the
process.
* speeds up TestCancelNoIO to cancel some contexts once no longer
needed, adding some comments about what the test is doing, adds some
TODOs, and reduces some overly-long sleeps.
This adds new http.Handler-based ServerTransport in the process,
reusing the HTTP/2 server code in x/net/http2 or Go 1.6+.
All end2end tests pass with this new ServerTransport.
Fixesgrpc/grpc-go#75
Also:
Updates grpc/grpc-go#495 (lets user fix it with middleware in front)
Updates grpc/grpc-go#468 (x/net/http2 validates)
Updates grpc/grpc-go#147 (possible with x/net/http2)
Updates grpc/grpc-go#104 (x/net/http2 does this)
The grpc-http2 transport doesn't validate hpack-decoded field names to be
valid http2 field names before checking their first byte. Had it verified
first and found that the empty string is illegal, this crash wouldn't happen,
but currently a malicious request can crash a gRPC server by sending an empty
hpack string.
The go race detector has a limit on how many goroutines it can track.
This test is only barely acceptable and the presence of any new
goroutines push it over the edge. Shorten this test is race mode.
The docs at https://golang.org/pkg/testing/#T.FailNow say:
> FailNow must be called from the goroutine running the test or
> benchmark function, not from other goroutines created during the
> test.
(Fatalf is documented as "Fatalf is equivalent to Logf followed by
FailNow.")
This was manifesting itself as a race with two concurrently failing
goroutines in my other CL, masking whatever the real problem was.
