Johnny Graettinger
Johnny Graettinger
See https://github.com/soheilhy/cmux/issues/76
An effective mitigation of this behavior is to set a non-zero `SetReadTimeout`. That timeout applies only while sniffing an appropriate mux, just after initial connection
Adding a test case is a TODO, but I'd first appreciate confirmation that the idea is acceptable.
Apologies for the delay. Reviewing the tests, switching over `tagMiddlware` appeared as a concise way to add coverage on ConstructorFunc without sacrificing coverage elsewhere, and that's what I've done here....
Bueller ?
This is arguably a bug within the Etcd client, which generally speaking takes on retry semantics if a particular Etcd member is unavailable. In the absence of that, Gazette could...
Digging into this, I'm hesitant to slap a retry on it because we _are_ using `FailFast(false)` or equivalently `WaitForReady(true)` on these and other calls, and per `WaitForReady` comments gRPC should...
FWIW, a work-around is to add an extra RecvMsg, for purposes of draining the EOF & causing the interceptor to run.
Hi -- FYI I've found this `/ready` behavior plays badly with StatefulSets using an "Ordered" [Pod Management Policy](https://kubernetes.io/docs/tutorials/stateful-application/basic-stateful-set/#pod-management-policy) (the default). I believe the fix is easy -- use a "Parallel"...
> Why is pod-0 marked as unhealthy? I can't understand this. I'm not sure. Looking at the code, the `/ready` state is supposed to latch. My observations in a couple...