kgiusti commented on a change in pull request #858:
URL: https://github.com/apache/qpid-dispatch/pull/858#discussion_r499807867
##########
File path: src/adaptors/http1/http1_client.c
##########
@@ -1202,8 +1220,11 @@ uint64_t
qdr_http1_client_core_link_deliver(qdr_http1_adaptor_t *adaptor,
_client_response_msg_t *rmsg = DEQ_TAIL(hreq->responses);
assert(rmsg && rmsg->dlv == delivery);
- if (!rmsg->dispo)
+ if (!rmsg->dispo) {
rmsg->dispo = _encode_response_message(hreq, rmsg);
+ hreq->base.stop = qd_timer_now();
Review comment:
By INFO I mean 100 Continue. In the case of 100 Continue this codepath
will be executed twice: once when the 100 Continue is encoded and again when
the terminal response arrives. So basically there are two response messages
for a single request.
I'm afraid I'm being dense regarding the definition of latency - or more
specifically what is included in the duration we're calling latency. I'm
assuming latency is going to include the time the server spends processing the
request if we're running the timer until the response is encoded (otherwise we
could try stopping the timer when the server sends the terminal disposition for
the request).
If we're timing the whole enchilada (server processing and full response
encoding) we'd probably want to stop the timer in the request_complete callback.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
