Ok, so you can ignore my comment about the incomplete payload being sent.
It is just that it is being sent in 2 frames as "partial entities".
But I am still wondering why there is a context deadline exceeded which
then results in a RST_STREAM with CANCEL being sent by my client ?
it's just 100ms which have elapsed since the last part of the payload was
sent in the DATA frame.
On Wednesday, 11 May 2022 at 07:47:15 UTC+10 envee wrote:
> Thanks for your reply, Robert.
>
> I enabled GODEBUG for http2 in my client application and noticed the
> following sequence of log lines for any particular stream for which I see
> my client sending an RST_STREAM frame.
>
> 2022/05/10 21:59:12.827474 http2: Framer 0xc23f448000: wrote HEADERS
> flags=END_HEADERS stream=247467 len=65
> 2022/05/10 21:59:12.896018 http2: Framer 0xc23f448000: wrote DATA
> stream=247467 len=75 data="{\n\t\"invocationSequenceNumber\":
> 1,\n\t\"invocationTimeStamp\": \"2022-05-10T11:59"
> 2022/05/10 21:59:12.996612 RoundTrip failure: context deadline exceeded
> 2022/05/10 21:59:12.996692 http2: Framer 0xc23f448000: wrote RST_STREAM
> stream=247467 len=4 ErrCode=CANCEL
>
> Usually, the payload that I send in my DATA frame is of size ~2400 bytes.
> And for such "successful" requests in the logs I can see that it only
> prints some part and says "(2153 bytes omitted)". That is fair enough.
>
> But in this erroneous case, the DATA frame size is shown as 75 bytes and
> the log line does not contain any such extra information about "omitting
> bytes" from the log.
> I am wondering if my client failed to upload the entire JSON payload and
> hence this caused it to timeout waiting for Header.
>
> My client timeout is set to 5seconds, but with the logs being shown for
> the particular failing stream, why is there a timeout after just 100
> milli-seconds i.e. between sending off the DATA frame and waiting for
> HEADER frame ?
>
> On Tuesday, 10 May 2022 at 22:49:25 UTC+10 ren...@ix.netcom.com wrote:
>
>> Conn.Error() should give you the underlying error as well.
>>
>>
>> On May 10, 2022, at 7:47 AM, robert engels <ren...@ix.netcom.com> wrote:
>>
>> I would add some logging to
>>
>> func (cs *clientStream) cleanupWriteRequest(err error)
>>
>> but you should be getting the underlying error when you perform the next
>> write on the stream - maybe you are not processing this error properly
>> (there is a code - CANCEL, but also an err).
>>
>> On May 10, 2022, at 6:59 AM, Robert Engels <ren...@ix.netcom.com> wrote:
>>
>> Set a breakpoint on the RST_STREAM generation and run under the debugger.
>>
>> On May 10, 2022, at 4:18 AM, envee <neeraj....@gmail.com> wrote:
>>
>> Hi All, I am using a Go HTTP/2 client (no SSL) to send requests at the
>> rate of around 3000 transactions per second (TPS) to a Web-server which is
>> based on Netty.
>>
>> At lower rates of say around 500 TPS , I do not see this issue, but at
>> rates as high as 2500 - 3000 TPS, I can see that my Go HTTP/2 client sends
>> RST_STREAM frame right after transmitting the JSON payload via the DATA
>> frame. The Error in the RST_STREAM is seen as CANCEL even though the
>> response from the server for the Request has not been received. Also, there
>> is no timeout that has occured which might cause this.
>>
>> This occurs for some requests and not all, maybe about 100 out of the
>> 3000 per second.
>>
>> If you observe the screenshot attached, the HEADER is transmitted in
>> packet 118847 in stream id 49765. The DATA frame is in packet 122113.
>>
>> Right after that, the client transmits RST_STREAM for stream id 49765 in
>> packet 122277.
>>
>> And then this results in an error on the response from the Server in
>> packet 122483 and 122485 which says "Request stream 49765 is not correct
>> for server connection"
>>
>> Any clues what could be causing this issue of the client sending
>> RST_STREAM before receiving the HTTP response from the server ?
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/56766546-356f-4901-b3d1-827be5bb0947n%40googlegroups.com
>>
>> <https://groups.google.com/d/msgid/golang-nuts/56766546-356f-4901-b3d1-827be5bb0947n%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>> <Screenshot 2022-05-10 190439.png>
>>
>>
>>
>>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/1896d1d0-13e0-42b8-a4a3-a2b9065d99bbn%40googlegroups.com.
