On Tuesday, May 10, 2022 at 12:19:57 PM UTC+8 Amnon wrote:
> OT, but why do you want to support the Go 1.15 toolchain?
> 1.15 and 1.16 are no longer supported upstream, so will not get essential
> security fixes.
> Why not just ask your users to upgrade to 1.18.1?
>
I can recommend but not for
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
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_HE
Hello gophers,
We have just released Go versions 1.18.2 and 1.17.10, minor point releases.
These minor releases include one security fix following the security policy:
• syscall: fix Faccessat on Linux
When called with a non-zero flags parameter, the Faccessat function could
incorrectly repor
* Amnon [220510 12:52]:
> > I'm not sure why w.Write would freeze; is your process starting to swap
> > and it is not really frozen but just taking a long time? Is it being
> > killed by the kernel's out-of-memory monitor?
>
> In the OP's code, w.Write was writing a large amount of data to a pipe
> I'm not sure why w.Write would freeze; is your process starting to swap
> and it is not really frozen but just taking a long time? Is it being
> killed by the kernel's out-of-memory monitor?
In the OP's code, w.Write was writing a large amount of data to a pipe,
while nothing was reading from t
Oh, thanks! I will rewrite that.
On Tuesday, May 10, 2022 at 2:56:28 AM UTC+8 Ian Lance Taylor wrote:
> On Mon, May 9, 2022 at 8:59 AM MQTT Tactic wrote:
> >
> > First I use LLVM PASS to extract all of the functions from the LLVM
> bitcode that compiled by `gollvm`. What I got is as follows:
>
* Const V [220508 17:20]:
> Using r.ReadLine repeatedly I was able to read the full line in memory. It
> is working very fast.
>
> for isPrefix && err == nil {
> line, isPrefix, err = r.ReadLine()
> ln = append(ln, line...)
> }
>
> if strings.Contains(s, "error") {
>
> finds the substring very
Conn.Error() should give you the underlying error as well.
> On May 10, 2022, at 7:47 AM, robert engels 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
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
Set a breakpoint on the RST_STREAM generation and run under the debugger.
> On May 10, 2022, at 4:18 AM, envee 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.
>
>
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
12 matches
Mail list logo
