Re: Travis Matrix (was: Re: [PATCH] wurfl device detection build fixes and dummy library)

2019-06-13 Thread Willy Tarreau
On Fri, Jun 14, 2019 at 01:34:34AM +0500, ??? wrote: > well, I am going to play with cron jobs say "after haproxy-2.0 release" OK, that works for me! > as for being good citizens, when I look at > > https://travis-ci.org/openssl/openssl/builds > > (25k builds 1hr each ), I'm sure

Re: Increase in sockets in TIME_WAIT with 1.9.x

2019-06-13 Thread Willy Tarreau
On Thu, Jun 13, 2019 at 05:31:09PM -0500, Dave Chiluk wrote: > I was able to bisect this down to 53216e7 being the problematic commit, > when using calls to setsockopt(... SO_LINGER ...) as the test metric. Oh great, thank you for doing this! > I used the number of calls to setsockopt with

Re: Increase in sockets in TIME_WAIT with 1.9.x

2019-06-13 Thread Dave Chiluk
I was able to bisect this down to 53216e7 being the problematic commit, when using calls to setsockopt(... SO_LINGER ...) as the test metric. I used the number of calls to setsockopt with SO_LINGER in them using the following command. $ sudo timeout 60s strace -e setsockopt,close -p $(ps -lf -C

Re: Travis Matrix (was: Re: [PATCH] wurfl device detection build fixes and dummy library)

2019-06-13 Thread Илья Шипицин
пт, 14 июн. 2019 г. в 01:27, Willy Tarreau : > On Thu, Jun 13, 2019 at 10:28:19PM +0500, ??? wrote: > > > > or we can drop boringssl build in favour of Manu :) > > > > > > I suggest to drop BoringSSL. It's not intended to be used outside of > > > Google anyway. So if it breaks the user

Re: Increase in sockets in TIME_WAIT with 1.9.x

2019-06-13 Thread Willy Tarreau
On Thu, Jun 13, 2019 at 03:20:20PM -0500, Dave Chiluk wrote: > I've attached an haproxy.cfg that is as minimal as I felt comfortable. (...) many thanks for this, Dave, I truly appreciate it. I'll have a look at it hopefully tomorrow morning. Willy

Re: Travis Matrix (was: Re: [PATCH] wurfl device detection build fixes and dummy library)

2019-06-13 Thread Willy Tarreau
On Thu, Jun 13, 2019 at 10:28:19PM +0500, ??? wrote: > > > or we can drop boringssl build in favour of Manu :) > > > > I suggest to drop BoringSSL. It's not intended to be used outside of > > Google anyway. So if it breaks the user gets to keep both pieces and can > > report the issue in

Re: Increase in sockets in TIME_WAIT with 1.9.x

2019-06-13 Thread Dave Chiluk
I've attached an haproxy.cfg that is as minimal as I felt comfortable. We are using admin sockets for dynamic configuration of backends so left the server-templating in, but no other application was configured to orchestrate haproxy at the time of testing. I've also attached output from $ sudo

Re: Travis Matrix (was: Re: [PATCH] wurfl device detection build fixes and dummy library)

2019-06-13 Thread Илья Шипицин
чт, 13 июн. 2019 г. в 22:25, Tim Düsterhus : > Ilya, > Willy, > > Am 13.06.19 um 19:11 schrieb Илья Шипицин: > > чт, 13 июн. 2019 г. в 22:07, Willy Tarreau : > > > >> On Thu, Jun 13, 2019 at 10:01:52PM +0500, ??? wrote: > >>> "everything enabled" is impossible. 51degrees may be enabled

Re: Travis Matrix (was: Re: [PATCH] wurfl device detection build fixes and dummy library)

2019-06-13 Thread Tim Düsterhus
Ilya, Willy, Am 13.06.19 um 19:11 schrieb Илья Шипицин: > чт, 13 июн. 2019 г. в 22:07, Willy Tarreau : > >> On Thu, Jun 13, 2019 at 10:01:52PM +0500, ??? wrote: >>> "everything enabled" is impossible. 51degrees may be enabled in two >>> mutually exclusive ways. it doubles number of

Re: Travis Matrix (was: Re: [PATCH] wurfl device detection build fixes and dummy library)

2019-06-13 Thread Willy Tarreau
On Thu, Jun 13, 2019 at 10:01:52PM +0500, ??? wrote: > "everything enabled" is impossible. 51degrees may be enabled in two > mutually exclusive ways. it doubles number of build configurations. It's not big deal, the haproxy-specific code remains the same and only the 51D-specific one

Re: Travis Matrix (was: Re: [PATCH] wurfl device detection build fixes and dummy library)

2019-06-13 Thread Willy Tarreau
On Thu, Jun 13, 2019 at 06:28:09PM +0200, Tim Düsterhus wrote: > I'm unhappy with that patch: > > a) It makes unrelated changes to the OpenSSL version (that should be a > separate patch). I'm also at fault here because I saw this and didn't bother that much, being busy on other stuff :-/ > b)

Re: Travis Matrix (was: Re: [PATCH] wurfl device detection build fixes and dummy library)

2019-06-13 Thread Илья Шипицин
чт, 13 июн. 2019 г. в 21:28, Tim Düsterhus : > Ilya, > > (removed Ben and Christopher from Cc, as this no longer about 51d) > > Am 13.06.19 um 17:01 schrieb Илья Шипицин: > > please find "travis-ci + 51degree" patch attached. > > I'm unhappy with that patch: > > a) It makes unrelated changes to

Re: Travis Matrix (was: Re: [PATCH] wurfl device detection build fixes and dummy library)

2019-06-13 Thread Илья Шипицин
чт, 13 июн. 2019 г. в 21:28, Tim Düsterhus : > Ilya, > > (removed Ben and Christopher from Cc, as this no longer about 51d) > > Am 13.06.19 um 17:01 schrieb Илья Шипицин: > > please find "travis-ci + 51degree" patch attached. > > I'm unhappy with that patch: > > a) It makes unrelated changes to

Travis Matrix (was: Re: [PATCH] wurfl device detection build fixes and dummy library)

2019-06-13 Thread Tim Düsterhus
Ilya, (removed Ben and Christopher from Cc, as this no longer about 51d) Am 13.06.19 um 17:01 schrieb Илья Шипицин: > please find "travis-ci + 51degree" patch attached. I'm unhappy with that patch: a) It makes unrelated changes to the OpenSSL version (that should be a separate patch). b) It

RE: [PATCH] wurfl device detection build fixes and dummy library

2019-06-13 Thread Ben Shillito
Hi Willy, Great, thanks. Yeah that makes total sense. Don't want warnings that can't be solved. Regards, Ben Shillito Developer O: +44 1183 287152 E: b...@51degrees.com T: @51Degrees -Original Message- From: Willy Tarreau [mailto:w...@1wt.eu] Sent: 13 June 2019 17:06 To: Ben Shillito

Re: [PATCH] wurfl device detection build fixes and dummy library

2019-06-13 Thread Willy Tarreau
On Thu, Jun 13, 2019 at 03:57:04PM +, Ben Shillito wrote: > Also, after thinking earlier about making it more obvious that it is a dummy > library, I have attached a patch which adds "(dummy library)" to the output > of REGISTER_BUILD_OPTS macro. Ah perfect, I also wanted to do it but

RE: [PATCH] wurfl device detection build fixes and dummy library

2019-06-13 Thread Ben Shillito
Same here. I can't see anything related to 51Degrees in there. I will leave this for now, but let me know if either of you notice anything I need to look into. Also, after thinking earlier about making it more obvious that it is a dummy library, I have attached a patch which adds "(dummy

Re: [PATCH 0/1] compression: Set Vary: Accept-Encoding

2019-06-13 Thread Tim Düsterhus
Willy, Am 13.06.19 um 17:26 schrieb Willy Tarreau: > On Wed, Jun 12, 2019 at 10:36:51PM +0200, Tim Duesterhus wrote: >> Willy, >> >> First things first: >> >> Yes, I'm aware that this is shortly before 2.0. Either put this into 2.0 >> or put this into `next` if you consider it too risky (or just

Re: [PATCH] wurfl device detection build fixes and dummy library

2019-06-13 Thread Willy Tarreau
On Thu, Jun 13, 2019 at 03:21:36PM +, Ben Shillito wrote: > Thanks both, > > Ilya, I will take a look at that now. I suspect it's totally unrelated, the failure was on this reg test and may be just a race : ## Test case: reg-tests/checks/4be_1srv_health_checks.vtc ## ## test results

Re: [PATCH 0/1] compression: Set Vary: Accept-Encoding

2019-06-13 Thread Willy Tarreau
Hi Tim, On Wed, Jun 12, 2019 at 10:36:51PM +0200, Tim Duesterhus wrote: > Willy, > > First things first: > > Yes, I'm aware that this is shortly before 2.0. Either put this into 2.0 > or put this into `next` if you consider it too risky (or just wait until > 2.0 release before merging). I had

RE: [PATCH] wurfl device detection build fixes and dummy library

2019-06-13 Thread Ben Shillito
Thanks both, Ilya, I will take a look at that now. Ben Shillito Developer [51Degrees] O: +44 1183 287152 E: b...@51degrees.com [https://51degrees.com/portals/0/images/twitterbird.png]

Re: [PATCH] wurfl device detection build fixes and dummy library

2019-06-13 Thread Илья Шипицин
Ben, I enabled "trie" on one build configuration and ... it failed https://travis-ci.com/haproxy/haproxy/jobs/207816969 it never failed before. can you have a look ? (also, it did NOT fail in my own fork) чт, 13 июн. 2019 г. в 20:03, Willy Tarreau : > On Thu, Jun 13, 2019 at 08:01:14PM +0500,

Re: [PATCH] wurfl device detection build fixes and dummy library

2019-06-13 Thread Willy Tarreau
On Thu, Jun 13, 2019 at 08:01:14PM +0500, ??? wrote: > please find "travis-ci + 51degree" patch attached. applied, thanks Ilya. willy

Re: [PATCH] wurfl device detection build fixes and dummy library

2019-06-13 Thread Илья Шипицин
please find "travis-ci + 51degree" patch attached. чт, 13 июн. 2019 г. в 19:06, Willy Tarreau : > On Thu, Jun 13, 2019 at 02:02:33PM +, Ben Shillito wrote: > > Hi Willy, > > > > Yes, I agree the paths in the dummy library should match that of the > actual library. And yes, that patch is good

Re: [PATCH] server state: cleanup and load global file in a tree

2019-06-13 Thread Baptiste
Last mail, this is not backportable. HAProxy 2.0+ only. On Thu, Jun 13, 2019 at 4:12 PM Baptiste wrote: > these patches replace to 2 previous ones. I fixed a compilation warning > about possible used of uninitialized variable in the second patch. > I also ran the reg-tests successfully. > >

Re: [PATCH] server state: cleanup and load global file in a tree

2019-06-13 Thread Baptiste
these patches replace to 2 previous ones. I fixed a compilation warning about possible used of uninitialized variable in the second patch. I also ran the reg-tests successfully. Cheers > From 0c5b17976ec703b12040d813bdd6ac975af7b4d7 Mon Sep 17 00:00:00 2001 From: Baptiste Assmann Date: Thu, 13

Re: [PATCH] wurfl device detection build fixes and dummy library

2019-06-13 Thread Willy Tarreau
On Thu, Jun 13, 2019 at 02:02:33PM +, Ben Shillito wrote: > Hi Willy, > > Yes, I agree the paths in the dummy library should match that of the actual > library. And yes, that patch is good with me. Thanks for the fast response, now merged. Willy

RE: [PATCH] wurfl device detection build fixes and dummy library

2019-06-13 Thread Ben Shillito
Hi Willy, Yes, I agree the paths in the dummy library should match that of the actual library. And yes, that patch is good with me. Thanks, Ben Shillito Developer O: +44 1183 287152 E: b...@51degrees.com T: @51Degrees -Original Message- From: Willy Tarreau [mailto:w...@1wt.eu] Sent:

Re: [PATCH] wurfl device detection build fixes and dummy library

2019-06-13 Thread Willy Tarreau
Ben, what do you think of this one ? Willy commit 5e4c5003c5cd5709e599aedbfdd5ef223dd3dc79 Author: Willy Tarreau Date: Thu Jun 13 15:56:10 2019 +0200 CLEANUP: 51d: move the 51d dummy lib to contrib/51d/src to match the real lib This way the directory structure remains the same

[PATCH] server state: cleanup and load global file in a tree

2019-06-13 Thread Baptiste
Hi all, Please find enclosed to this email a couple of patches: 0001: cleans up the server state code to match on server names only (since 7da71293e431b5ebb3d6289a55b0102331788ee6, server name is a reliable information) 0002: loads global server state file in a tree for fast processing. As an

Re: [PATCH] BUILD: Silence gcc warning about unused return value

2019-06-13 Thread Willy Tarreau
Hi guys, On Wed, Jun 12, 2019 at 10:31:37PM +0200, Vincent Bernat wrote: > ? 12 juin 2019 20:47 +02, Tim Duesterhus : > > > - write(2, trash.area, trash.data); > > + shut_your_big_mouth_gcc(write(2, trash.area, trash.data)); Now merged, thanks Tim! > An alternative not discussed in

Re: [PATCH] wurfl device detection build fixes and dummy library

2019-06-13 Thread Willy Tarreau
On Thu, Jun 13, 2019 at 12:59:33PM +, Ben Shillito wrote: > Thanks for the link, that's useful. Looks like the path to the source is the > issue. > > It should be "51DEGREES_SRC=contrib/51d/pattern" rather than > "51DEGREES_SRC=contrib/51d/src/pattern". That's what I just noticed as well,

RE: [PATCH] wurfl device detection build fixes and dummy library

2019-06-13 Thread Ben Shillito
Thanks for the link, that’s useful. Looks like the path to the source is the issue. It should be “51DEGREES_SRC=contrib/51d/pattern” rather than “51DEGREES_SRC=contrib/51d/src/pattern”. On your performance point, the Pattern algorithm offers the match metrics and is a bit more thorough in

Re: [PATCH] wurfl device detection build fixes and dummy library

2019-06-13 Thread Илья Шипицин
чт, 13 июн. 2019 г. в 17:09, Ben Shillito : > In Travis the contrib version would be fine. But if you are testing > something which will later be deployed to production, I would suggest using > cloning the actual GitHub repo instead to be safe. > this is how I enable it on travis-ci

RE: [PATCH] wurfl device detection build fixes and dummy library

2019-06-13 Thread Ben Shillito
In Travis the contrib version would be fine. But if you are testing something which will later be deployed to production, I would suggest using cloning the actual GitHub repo instead to be safe. In answer to your other question, yes, Pattern and Trie in HAProxy are mutually exclusive. Which

Re: Haproxy 1.9.8 comsumes 100% CPU

2019-06-13 Thread Aleksandar Lazic
Am 13.06.2019 um 13:47 schrieb Akom II: > Hello, >    Ubuntu 18.04  and haproxy 1.9.8 with latest patch on 2019/06/08 >    I'm currently encounter haproxy consume all CPU core, at the begging I > curious might relate  to peers function which is our app rely heavily on > those , > it happen quite

Haproxy 1.9.8 comsumes 100% CPU

2019-06-13 Thread Akom II
Hello, Ubuntu 18.04 and haproxy 1.9.8 with latest patch on 2019/06/08 I'm currently encounter haproxy consume all CPU core, at the begging I curious might relate to peers function which is our app rely heavily on those , it happen quite fast after restart service for couple minutes then

Re: Idea + question regarding the build targets

2019-06-13 Thread Илья Шипицин
as for popular distro, for example fedora, I'd spent some time on packaging rpm in fedora copr (rather than telling people proper Makefile options). if there's an interest in "official" package distro, I'd take part with fedora copr and maybe few others ср, 12 июн. 2019 г. в 10:41, Willy Tarreau

Re: [PATCH] wurfl device detection build fixes and dummy library

2019-06-13 Thread Илья Шипицин
чт, 13 июн. 2019 г. в 15:25, Ben Shillito : > Hi, > > > > The docs are correct. However, the 51Degrees source in the “contrib” > directory should only be used for testing changes to the HAProxy source. > The code contained in here does not contain any 51Degrees functionality, > just method stubs

RE: [PATCH] wurfl device detection build fixes and dummy library

2019-06-13 Thread Ben Shillito
Hi, The docs are correct. However, the 51Degrees source in the “contrib” directory should only be used for testing changes to the HAProxy source. The code contained in here does not contain any 51Degrees functionality, just method stubs to enable compilation and testing. You should use the

Re: [PATCH] wurfl device detection build fixes and dummy library

2019-06-13 Thread Илья Шипицин
Ben, what is the proper way of building 51degree ? I added "USE_51DEGREES=1 51DEGREES_SRC=contrib/51d/src/pattern" (as I seen in documentation) gcc -Iinclude -Iebtree -Wall -Wextra -O2 -fno-strict-aliasing -Wdeclaration-after-statement -fwrapv -Wno-unused-label -Wno-sign-compare

Re: [PR] MINOR: doc: Remove -Ds option in man page

2019-06-13 Thread William Lallemand
On Thu, Jun 13, 2019 at 09:23:04AM +, PR Bot wrote: > Description: >`-Ds` option should be removed from man page. It is no longer >supported as this commit shows: https://github.com/haproxy/haproxy/com >mit/095ba4c2428ec8bcccb134b3d24f07de2aabbdcd > >I noticed that >the

[PR] MINOR: doc: Remove -Ds option in man page

2019-06-13 Thread PR Bot
Dear list! Author: Kazuo Yagi Number of patches: 1 This is an automated relay of the Github pull request: MINOR: doc: Remove -Ds option in man page Patch title(s): MINOR: doc: Remove -Ds option in man page Link: https://github.com/haproxy/haproxy/pull/120 Edit locally: wget

Re: Increase in sockets in TIME_WAIT with 1.9.x

2019-06-13 Thread Willy Tarreau
On Wed, Jun 12, 2019 at 12:08:03PM -0500, Dave Chiluk wrote: > I did a bit more introspection on our TIME_WAIT connections. The increase > in sockets in TIME_WAIT is definitely from old connections to our backend > server instances. Considering the fact that this server is doesn't > actually