Steve Jenson

it's worth noting that gRPC won't send credentials over an unencrypted channel and this test was done without TLS so I will re-run all of these credential failure test cases...

non-per-endpoint metric: Unique number of currently connected clients. I would have expected 1 when running my load test with a concurrency of 1. Seeing > 1 would have led me...

Looking at a healthy linkerd, I also see 3 threads all waiting on the same mutex so that must not be what is causing this issue.

Attached is a txt file of `rust-gdb` output of backtraces of threads on a healthy linkerd-tcp. [healthy_linkerd_gdb.txt](https://github.com/linkerd/linkerd-tcp/files/883867/healthy_linkerd_gdb.txt)

Should I take this opportunity to bump linkerd-tcp to 0.0.3?

Good news: the same process will happily route requests after being in this state ``` stevej@netty-test-8:~$ ./slow_cooker_linux_amd64 -host 'default' -totalRequests 1000000 -qps 100 -concurrency 100 http://proxy-test-4d:7474/ # sending 10000 req/s...

High concurrency even at low qps seems to cause this ``` stevej@netty-test-8:~$ ./slow_cooker_linux_amd64 -qps 1 -concurrency 1000 http://proxy-test-4d:7474 # sending 1000 GET req/s with concurrency=1000 to http://proxy-test-4d:7474 ... # good/b/f...

I haven't dug into tcpdump yet but I'll note this doesn't happen when the backends and test client are all on localhost.