Re: [PATCH] MEDIUM: Support TCP keepalive parameters customization

2020-07-08 Thread Willy Tarreau
On Thu, Jul 09, 2020 at 04:25:17AM +, mizuta.take...@fujitsu.com wrote: > Hi, Willy, > > Thank you for your support. > Sorry for not considering other platforms. No worries, that's exactly part of the reasons I preferred to merge this after the 2.2 release :-) Willy

RE: [PATCH] MEDIUM: Support TCP keepalive parameters customization

2020-07-08 Thread mizuta.take...@fujitsu.com
Hi, Willy, Thank you for your support. Sorry for not considering other platforms. Best regards, MIZUTA Takeshi > -Original Message- > From: Willy Tarreau > Sent: Thursday, July 9, 2020 1:09 PM > To: Mizuta, Takeshi/水田 健司 > Cc: 'haproxy@formilux.org' > Subject: Re: [PATCH] MEDIUM:

OSX builds in Travis

2020-07-08 Thread Willy Tarreau
Hi Ilya, is it normal that the OSX build procedure in travis pulls gigabytes of ruby and python crap, including fonts, libgpg, gnutls, qt, postgresql and whatnot for many minutes ? https://travis-ci.com/github/haproxy/haproxy/jobs/359124175 It's been doing this for more than 12 minutes now

Re: [PATCH] MEDIUM: Support TCP keepalive parameters customization

2020-07-08 Thread Willy Tarreau
On Thu, Jul 09, 2020 at 04:42:29AM +0200, Willy Tarreau wrote: > On Thu, Jul 09, 2020 at 02:21:32AM +, mizuta.take...@fujitsu.com wrote: > > I have attached a patch with dual-sided tcpka-* removed. > > OK thank you, that's perfect, I'm taking it now! Bah, we obviously broke non-linux builds,

Re: [PATCH] MEDIUM: Support TCP keepalive parameters customization

2020-07-08 Thread Willy Tarreau
On Thu, Jul 09, 2020 at 02:21:32AM +, mizuta.take...@fujitsu.com wrote: > Hi, Willy, > > > Given that even in the doc you strongly suggested to use only clika-* and > > srvka-*, I'd rather kill the dual-sided tcpka-* before they start to be > > used. > > Thank you for your suggestion! > >

RE: [PATCH] MEDIUM: Support TCP keepalive parameters customization

2020-07-08 Thread mizuta.take...@fujitsu.com
Hi, Willy, > Given that even in the doc you strongly suggested to use only clika-* and > srvka-*, I'd rather kill the dual-sided tcpka-* before they start to be used. Thank you for your suggestion! Since clitcpka and srvtcpka have the dual-sided tcpka, I constructed these dual-sided parameters

Re: [ANNOUNCE] haproxy-2.2.0

2020-07-08 Thread Willy Tarreau
On Wed, Jul 08, 2020 at 07:53:51PM +0200, Luke Seelenbinder wrote: > > We would then pick from the first > > list and if it's empty, then the next one. > > This slightly concerns me. Hopefully I'm just not quite understanding the > behavior. > > Would that imply request A would pick from the

Re: [ANNOUNCE] haproxy-2.2.0

2020-07-08 Thread Luke Seelenbinder
Hi Willy, Thanks for your tome treatment of my ideas! I forgot how much I enjoyed reading them. :) >> To dig up an old discussion--I took a look at better support for SRV records >> (using the priority field as backup/non-backup, etc.) a few weeks ago, but >> determined it didn't make sense in

Re: [ANNOUNCE] haproxy-2.2.0

2020-07-08 Thread Willy Tarreau
Hi Luke! On Wed, Jul 08, 2020 at 11:57:15AM +0200, Luke Seelenbinder wrote: > I've been following along the torturous road, and I'm happy to see all the > issues resolved and the excellent results. You can imagine how I am as well :-) > Personally, I'm excited about the > performance gains.

Re: [ANNOUNCE] haproxy-2.2.0

2020-07-08 Thread Luke Seelenbinder
Congrats on the release, Willy & the rest of the team! I've been following along the torturous road, and I'm happy to see all the issues resolved and the excellent results. Personally, I'm excited about the performance gains. I'll deploy this soon on our network. To dig up an old discussion—I

Re: [PATCH] MEDIUM: Support TCP keepalive parameters customization

2020-07-08 Thread Willy Tarreau
Hi, On Mon, Jul 06, 2020 at 03:01:26AM +, mizuta.take...@fujitsu.com wrote: > Hi, Willy, > > Thank you for your quick reply! > > > But I mean, that's probably OK and I won't argue on this. I'd be > > interested in others' opinions and/or suggestions on this, but > > it's not critical. > >