he raw buffer to htx
conversion, but there's probably other ways to fix it.
This should be backported to 2.0, and possible 1.9 if htx processing is used
for mode tcp with http header processing in 1.9, which I'm not sure about.
--
Richard Russo
to...@enslaves.us
0001-BUG-MAJOR-http-samp
Here are my current patches for comments.
--
Richard Russo
to...@enslaves.us
On Fri, Jul 5, 2019, at 12:23 PM, Richard Russo wrote:
> Hi,
>
> I've been experimenting with Recieve Side Scaling (RSS) for a tcp proxy
> application. The basic idea with RSS is by configur
's helpful for the discussion, I can share my patches as-is, but if there
are better ideas on how to structure this, I'd rather try to get the changes
done in a nice way before sharing.
Thanks!
--
Richard Russo
to...@enslaves.us
After the weekend, the test machine looks fine. Thanks!
--
Richard Russo
to...@enslaves.us
On Fri, Apr 12, 2019, at 10:33 AM, Richard Russo wrote:
> Thank you; I had missed the context from 1.9.6. I've updated my test
> machine and will report back on Monday (or earlier, if i
Thank you; I had missed the context from 1.9.6. I've updated my test machine
and will report back on Monday (or earlier, if it runs into trouble)
--
Richard Russo
to...@enslaves.us
On Fri, Apr 12, 2019, at 4:17 AM, Olivier Houchard wrote:
> Hi,
>
> On Fri, Apr 12, 2019 at 0
tand this section enough
to try to reproduce this, but I found several processes stuck here on a machine
testing from yesterday's HEAD.
Richard
--
Richard Russo
to...@enslaves.us
on that. I've added it in other work with
pretty good results; especially if you advertise one second less than you'll
actually wait, that would eliminate the request and close crossing in transit
except in case of missed packets and retransmits.
--
Richard Russo
to...@enslaves.us
On Thu, Mar 21
.
Richard
PS sorry for messing up threading, I'm not receiving messages from Olivier to
the list in my corporate mail; I'll move to my personal mail for the future.
On 2/20/19, 1:00 PM, "Richard Russo" wrote:
While testing haproxy 1.9 on FreeBSD 11.1, I would often find stuck threads
in connection.c:conn_fd_handle. I'm testing the NULL check right now, since
it's simplest. I haven't had a crash since, but that doesn't mean it won't
crash. This change would need to be applied to 1.8 as well, although I haven't
managed to observe a crash on 1.8.
On 2/20/19, 1:00 PM, "Richard Russo" wrote:
. I can
resend from a personal address in case that happens.
Thanks,
Richard
From 11903cdf9f9ac3236765e85b1849b0a26b2f7b51 Mon Sep 17 00:00:00 2001
From: Richard Russo
Date: Wed, 20 Feb 2019 12:43:45 -0800
Subject: [PATCH] BUG/MAJOR: fd/threads, task/threads: ensure all spin locks
are unlocked
Thanks Willy and Lukas,
I've tried your config suggestions; the system behavior seems to be pretty
similar to with accept filters. It's also simpler for me to deploy, so it's a
definitely win.
Thanks again!
On 2/1/19, 11:50 PM, "Willy Tarreau" wrote:
Hi Lukas,
On Sat, Feb 02,
Would you be interested in a patch to support FreeBSD accept filters? I've been
testing on my system with the dataready filter which is conceptually similar to
Linux's deferred accept, and it reduces processing for the connections that are
able to complete a TCP handshake but never actually
Hi,
The sample code provided at the end of the proxy protocol documentation [1]
doesn't match the description earlier in the doc. Specifically the header is
described as:
struct proxy_hdr_v2 {
uint8_t sig[12]; /* hex 0D 0A 0D 0A 00 0D 0A 51 55 49 54 0A */
uint8_t ver;
Is there a good way to handle SSL and non-ssl on the same port, with ssl
handled by HAProxy
I can do ex:
frontend maybessl
bind *:443
bind localhost:1443 ssl crt example.pem
acl client_hello req_ssl_hello_type 1
use_backend ssl if client_hello
default_backend clear
14 matches
Mail list logo
