This fixes the current ruby server interop test flakiness.
- The interop tests recently changed so that clients access servers in
parallel, meaning that the interop servers handle multiple rpcs at once,
which is how this bug became visible
- since this change, tests run against the ruby interop server have
failed sporadically
- the problem was that the block in #loop_handle_server_calls that is
passed to the thread pool referenced a var in an enclosing block,
which resulted in requests being processed by the wrong handler
- this fix ensures that the block to be run on the thread pool thread
does not have any references to vars in the enclosing block
The encoding of the issuer field in this cert is now a PRINTABLESTRING
as opposed to UTF8STRING in the previous server1.pem which was causing
the Go issue.
Fixes#4086.
If:
- one thread issues a kick forcing pollset re-evaluation
- concurrently with a second thread forcing a specific poller to be awoken
And:
- both threads kicks are processed as a single wakeup
Then:
- since we enqueue nothing to the exec_ctx in this situation, we responded to the wakeup by doing another poll until the timeout, ignoring urgent work up the stack
Fix this by flagging that a specific worker was designated to be awoken (since this is a good signal that we really really need to wake up), and use that to still re-evaluate the poll set, but with an immediate deadline so that we fall out of the poll loop as soon as possible.
For local running one can still tests AllTests, but for C.I. one can
test the 4 of them in parallel (and, importantly, deactivate the remote
interop tests until we fix them on Travis; while keeping the rest).
I had to make the remote tests a subclass of an abstract InteropTests
(like InteropTestsLocalSSL and InteropTestsLocalCleartext), and then
deactivate the abstract InteropTests on the 4 schemes that use it.