Re: ELB scaling => sudden backend tragedy

https://github.com/haproxy/haproxy/issues/341 On Thu, Oct 24, 2019 at 11:44 AM Lukas Tribus wrote: > Hello, > > On Thu, Oct 24, 2019 at 5:53 PM Jim Freeman wrote: > > > > Yesterday we had an ELB scale to 26 IP addresses, at which time ALL of > the servers in that backend were suddenly marked do

Re: [PATCH] MINOR: sample: add us/ms support to date sample

Damien, Am 24.10.19 um 17:49 schrieb Damien Claisse: > @@ -3259,7 +3275,7 @@ static struct sample_fetch_kw_list smp_kws = {ILH, { > { "always_false", smp_fetch_false, 0,NULL, SMP_T_BOOL, > SMP_USE_INTRN }, > { "always_true", smp_fetch_true, 0,NULL, SMP_T_BOOL

Research on Chord Progressions

Dear Editor, My name is Jen and I’m an Editor at Jen Reviews . I was doing research on chord progressions and just finished reading your wonderful piece: https://sock-raw.org/ In that article, I noticed that you cited a solid post that I’ve read in the past: https://m

Re: ELB scaling => sudden backend tragedy

Hello, On Thu, Oct 24, 2019 at 5:53 PM Jim Freeman wrote: > > Yesterday we had an ELB scale to 26 IP addresses, at which time ALL of the > servers in that backend were suddenly marked down, e.g. : > >Server www26 is going DOWN for maintenance (unspecified DNS error) > > Ergo, ALL requests to

RE: Lock contention in pat_match_str in threaded mode

Thank you for turning that around so quickly, Willy. We'll pull down the new release when it's available. -Original Message- From: Willy Tarreau Sent: Tuesday, October 22, 2019 10:53 PM To: Brian Diekelman Cc: haproxy@formilux.org Subject: Re: Lock contention in pat_match_str in threa

[ANNOUNCE] haproxy-1.9.12

Hi, HAProxy 1.9.12 was released on 2019/10/24. It added 39 new commits after version 1.9.11. This version addresses mostly the same issues as 2.0.8 yesterday. In addition it addresses a failed backport of the H2 connection timeout fix, which can cause some rare crashes if the timeout finally stri

ELB scaling => sudden backend tragedy

Yesterday we had an ELB scale to 26 IP addresses, at which time ALL of the servers in that backend were suddenly marked down, e.g. : Server www26 is going DOWN for maintenance (unspecified DNS error) Ergo, ALL requests to that backend got 503s ==> complete outage Mayhap src/dns.c::dns_validat

[PATCH] MINOR: sample: add us/ms support to date sample

It can be sometimes interesting to have a timestamp with a resolution of less than a second. It is currently painful to obtain this, because concatenation of date and date_us lead to a shorter timestamp during the first 100ms of a second, which is not parseable and needs ugly ACLs in configuration

Re: Haproxy tcp:80 and http:80 configuration difference without setting other http options

Yes, Thank you. In tcp mode, No need forwardfor. In my understanding, it add a field X-Forwarded-For in http header. Besides, Do they have differences in scheduling according to my configuration? 2019年10月24日 下午9:34，Aleksandar Lazic mailto:al-hapr...@none.at>> 写道： Hi. Am 24.10.19 um 13:05 sch

Re: Haproxy tcp:80 and http:80 configuration difference without setting other http options

Hi. Am 24.10.19 um 13:05 schrieb Zhengyu Pan(联通集团联通云数据有限公司本部): > Hi, > Does configuration mode tcp, port 80 and mode http, port 80 have differences > without setting other http options in Haproxy? No afaik, but `option forwardfor` is a http option which does not work in tcp mode. you should get

Haproxy tcp:80 and http:80 configuration difference without setting other http options

Hi, Does configuration mode tcp, port 80 and mode http, port 80 have differences without setting other http options in Haproxy? This is http:80 configuration: frontend 18857e04-cd6a-47a8-859e-38a7a4e0d8c5 option tcplog option forwardfor bind 0.0.0.0:80 mode http default_backend 86d030d2-4893-4c3

[PATCH] MINOR: ssl: deduplicate ca-file

Hi, Little patch with big win when ca-file is used in server line. ++ Manu 0001-MINOR-ssl-deduplicate-ca-file.patch Description: Binary data

Re: Possible optimization to 51d in multithread

thank you, Ben. there's one more "finding", I guess we just mark it as intentional (inside coverity itself), right ? 693#ifdef FIFTYONEDEGREES_H_PATTERN_INCLUDED CID 1403837 (#1 of 1): Calling risky function (DC.WEAK_CRYPTO)dont_call: random should not be used for security-related applications,

RE: Possible optimization to 51d in multithread

Hi, This is intentional, as the calling method would return early if the htx is null (this is assuming that smp_prefetch_htx will not return a different result the second time?): htx = smp_prefetch_htx(smp, chn, 1); if (!htx) return 0; Rather than doing the null check

Re: [PATCH] MINOR: tcp: avoid confusion in time parsing init

Le 23/10/2019 à 19:31, William Dauchy a écrit : if I'm not wrong, we never enter val_fc_time_value when an associated fetcher such as `fc_rtt` is called without argument. meaning `type == ARGT_STOP` will never be true and so the default `data.sint = TIME_UNIT_MS` will never be set. remove this pa

Re: Possible optimization to 51d in multithread

Hello, Ben. since you are going to touch 51d code, can you please review the following coverity finding (it thinks there might be null pointer dereference) ? 239 // No need to null check as this has already been carried out in the 240// calling method 2. returned_null: smp_prefetch_htx r