core: exclude client and hedging cancellations from callcounters for outlier-detection - #12923
core: exclude client and hedging cancellations from callcounters for outlier-detection#12923AgraVator wants to merge 15 commits into
Conversation
…ications with transport stream closure
This reverts commit f9dd0fb.
…portTest" This reverts commit 5e558a5.
| Status status, RpcProgress rpcProgress, Metadata trailers) { | ||
| if (!listenerClosed) { | ||
| listenerClosed = true; | ||
| if (status.getCode() == Status.Code.CANCELLED) { |
There was a problem hiding this comment.
This method is for transport callback for stream closure and it is too late at this point to make a distinction whether the cancellation is app/retriable stream initiated or from the remote endpoint. This should instead be done in method cancel that sets this.cancelled = true; and that call only happens for app/retriable stream initiated cancellation, and not for remote server initiated cancellations, and happens before the transport stream is closed.
There was a problem hiding this comment.
In addition, we would need the guard in AbstractClientStream.cancel against late cancellations:
@Override
public final void cancel(Status reason) {
Preconditions.checkArgument(!reason.isOk(), "Should not cancel with OK status");
if (cancelled || transportState().listenerClosed) { // <----- GUARD
return;
}
cancelled = true;
statsTraceCtx.clientCancelled(reason);
abstractClientStreamSink().cancel(reason);
}
There was a problem hiding this comment.
Placing statsTraceCtx.clientCancelled(reason) inside cancel() on the calling thread (app thread or deadline timer thread) could result in a race condition. Had it like that in the initial commits but then eric suggested to use transportReadyStatus() instead.
… detection call counter
a573991 to
bf90eb5
Compare
fixes #12834