maybe setting GODEBUG=http2debug=2 to spit out some logs?
On Monday, November 9, 2020 at 5:49:57 PM UTC+1 telyuk...@gmail.com wrote:
> Hello!
>
> I use third-party software with my own code to build reverse-proxy, which
> supports http/2. Sometimes requests hang up with infinite waiting. With
>
Thanks! Maybe it will help.
вт, 10 нояб. 2020 г. в 01:21, seank...@gmail.com :
> maybe setting GODEBUG=http2debug=2 to spit out some logs?
>
> On Monday, November 9, 2020 at 5:49:57 PM UTC+1 telyuk...@gmail.com wrote:
>
>> Hello!
>>
>> I use third-party software with my own code to build reverse-
More complex problem description with
images:
https://caddy.community/t/sometimes-http-2-request-hangs-up-need-help-with-debugging/10439/2
вторник, 10 ноября 2020 г. в 10:25:58 UTC+7, Denis Telyukh:
> Thanks! Maybe it will help.
>
> вт, 10 нояб. 2020 г. в 01:21, seank...@gmail.com :
>
>> may
You’ve most likely exhausted the network capacity. You need to use tools like
netperf and wireshark. Start with netstat and review the outgoing queue sizes.
> On Nov 10, 2020, at 4:46 AM, Denis Telyukh wrote:
>
> More complex problem description with images:
> https://caddy.community/t/somet
Thanks for your advice. But I have this problem on localhost also, I doubt
that problem in network capacity :-(
вт, 10 нояб. 2020 г. в 19:09, Robert Engels :
> You’ve most likely exhausted the network capacity. You need to use tools
> like netperf and wireshark. Start with netstat and review the
You can easily have the same problem on localhost if the producer is faster
than the consumer.
You can use netstat in the localhost as well.
> On Nov 10, 2020, at 9:36 AM, Denis Telyukh wrote:
>
>
> Thanks for your advice. But I have this problem on localhost also, I doubt
> that problem
1. Got some stuck requests
2. netstat -atp
tcp 25 0 dionysius-pc:52340 server-52-85-47-1:https
CLOSE_WAIT 1364/brave --type=u
tcp 25 0 dionysius-pc:40296 server-13-33-240-:https
CLOSE_WAIT 1364/brave --type=u
3. A few second later netstat doesn't show any non-e
On Tue, Nov 10, 2020 at 9:39 PM Denis Telyukh
wrote:
> 1. Got some stuck requests
> 2. netstat -atp
> tcp 25 0 dionysius-pc:52340 server-52-85-47-1:https
> CLOSE_WAIT 1364/brave --type=u
> tcp 25 0 dionysius-pc:40296 server-13-33-240-:https
> CLOSE_WAIT 1364/brav
OS: Manjaro 20.2 Nibia
Kernel: x86_64 Linux 5.4.74-1-MANJARO
ср, 11 нояб. 2020 г. в 12:59, Kurtis Rader :
> On Tue, Nov 10, 2020 at 9:39 PM Denis Telyukh
> wrote:
>
>> 1. Got some stuck requests
>> 2. netstat -atp
>> tcp 25 0 dionysius-pc:52340 server-52-85-47-1:https
>> CLOSE_WA
Better problem description after deeper
debugging: https://github.com/golang/go/issues/42534
среда, 11 ноября 2020 г. в 13:21:56 UTC+7, Denis Telyukh:
> OS: Manjaro 20.2 Nibia
> Kernel: x86_64 Linux 5.4.74-1-MANJARO
>
> ср, 11 нояб. 2020 г. в 12:59, Kurtis Rader :
>
>> On Tue, Nov 10, 2020 at 9
Your issue report describes the same issue.
If you switch to http rather than http2 do you have the same issue?
I am guessing that your consumer is blocked which eventually blocks your
producer when the buffers fill.
I would continue to use the networking tools to diagnose.
> On Nov 12, 202
One thing to note, gRPC uses http2. If there were a bug like this lurking in
the library it would be far more common, so the most likely cause is specific
to your code.
> On Nov 12, 2020, at 8:13 AM, Robert Engels wrote:
>
>
> Your issue report describes the same issue.
>
> If you switch
Could you, please, explain me what is producer in this case and what is
consumer? Is it web browser and web server? And what kind of anomalies do
you think I can find with netstat? I'm not sure what to look at, the
traffic seems fine to me.
Maybe this issue is related the same problem:
https:/
After reading that issue and the related ones there does appear to be a live
lock under heavy stress. I didn’t read too deeply because I am on a phone.
I am guessing a small reproducible test case is required. Since you encounter
it on localhost I assume you can extract what is needed based on
On Thursday, 12 November 2020 14:34:35 UTC, Robert Engels wrote:
>
> One thing to note, gRPC uses http2. If there were a bug like this lurking
> in the library it would be far more common, so the most likely cause is
> specific to your code.
>
To the OP: have you tried running your code under th
> If you switch to http rather than http2 do you have the same issue?
No, I haven't.
> have you tried running your code under the race detector?
Yes, I did.
> Since you encounter it on localhost I assume you can extract what is
needed based on the other issues cited.
It's not easy, but I could t
16 matches
Mail list logo