Frédéric Lécaille

Well. This is difficult to identify the reason why a connection or requests seem stalled from the client point of view. I prefer rely only on events from haproxy point...

Ok. So, I would say that this issue is more a performance issue than a bug. This is something we need to improve: RX performance.

Due to the last architectural modifications, I guess there is a bottleneck issue which appeared at the connection level when the RX buffer attached to a connection is full. The...

Well, of course the calls to printf() do not accelerate the process. We should replace them by something else which would not hide this issue. I also think it would...

@Tristan971 I do not know if you are familiar with C syntax and file patching. I am able to get similar traces but only when I use POST requests. The...

here is the patch file: [conn_rx_buf.txt](https://github.com/haproxy/haproxy/files/8873547/conn_rx_buf.txt)

> I have no idea whether that is an appropriate fix for closing this issue or if it was just an experiment, so I'll let you be the judge of...

Just to let you know we are working on this issue. But it is not an easy one to fix.

@Tristan971 FYI with the current development version of haproxy, in case of RX buffer overrun, no more messages will be printed on stderr anymore. But we added a new stats...

Hello, this is really weird. cubic_root() does not seem buggy to me. Could you try to compile again haproxy without with this CFLAGS option please : -ggdb3