Re: Early connection close, incomplete transfers
On 2019-02-14 18:29, Aleksandar Lazic wrote: Replaced HAproxy with Nginx for testing and with Nginx, not a single connection was interrupted, did millions of requests. In 1.9.4 are a lot of fixed added. please can you try your tests with 1.9.4, thanks. Already did before writing my previous letter. No differencies. Veiko
Re: Compilation fails on OS-X
On 2019/2/14 12:45, Olivier Houchard wrote: > Hi Patrick, > > On Thu, Feb 14, 2019 at 09:12:18AM -0500, Patrick Hemmer wrote: >> >> On 2019/2/14 08:20, Frederic Lecaille wrote: >>> On 2/14/19 1:32 PM, Frederic Lecaille wrote: On 2/13/19 7:30 PM, Patrick Hemmer wrote: > > On 2019/2/13 10:29, Olivier Houchard wrote: >> Hi Patrick, >> >> On Wed, Feb 13, 2019 at 10:01:01AM -0500, Patrick Hemmer wrote: >>> On 2019/2/13 09:40, Aleksandar Lazic wrote: Am 13.02.2019 um 14:45 schrieb Patrick Hemmer: > Trying to compile haproxy on my local machine for testing > purposes and am > running into the following: Which compiler do you use? >>> # gcc -v >>> Configured with: >>> --prefix=/Applications/Xcode.app/Contents/Developer/usr >>> --with-gxx-include-dir=/usr/include/c++/4.2.1 >>> Apple LLVM version 9.0.0 (clang-900.0.39.2) >>> Target: x86_64-apple-darwin17.7.0 >>> Thread model: posix >>> InstalledDir: >>> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin >>> >>> > # make TARGET=osx > src/proto_http.c:293:1: error: argument to 'section' > attribute is not > valid for this target: mach-o section specifier requires a > segment and section > separated by a comma > DECLARE_POOL(pool_head_http_txn, "http_txn", > sizeof(struct http_txn)); > ^ > include/common/memory.h:128:2: note: expanded from > macro 'DECLARE_POOL' > REGISTER_POOL(&ptr, name, size) > ^ > include/common/memory.h:123:2: note: expanded from > macro 'REGISTER_POOL' > INITCALL3(STG_POOL, > create_pool_callback, (ptr), (name), > (size)) > ^ > include/common/initcall.h:102:2: note: expanded from > macro 'INITCALL3' > _DECLARE_INITCALL(stage, __LINE__, > function, arg1, arg2, > arg3) > ^ > include/common/initcall.h:78:2: note: expanded from macro > '_DECLARE_INITCALL' > __DECLARE_INITCALL(__VA_ARGS__) > ^ > include/common/initcall.h:65:42: note: expanded from macro > '__DECLARE_INITCALL' > __attribute__((__used__,__section__("init_"#stg))) = \ > > > > Issue occurs on master, and the 1.9 branch > > -Patrick >> Does the (totally untested, because I have no Mac to test) patch >> works for >> you ? > Unfortunately not. Just introduces a lot of new errors: > > > In file included from src/ev_poll.c:22: > In file included from include/common/hathreads.h:26: > include/common/initcall.h:134:22: error: expected ')' > DECLARE_INIT_SECTION(STG_PREPARE); > ^ > include/common/initcall.h:134:1: note: to match this '(' > DECLARE_INIT_SECTION(STG_PREPARE); > ^ > include/common/initcall.h:124:82: note: expanded from macro > 'DECLARE_INIT_SECTION' > extern __attribute__((__weak__)) const struct > initcall *__start_init_##stg __asm("section$start$__DATA$" stg); \ > ^ Try to use -E in place of -c option of your compiler to stop after having preprocessed the code. Then have a look to how the code of src/ev_poll.c was preprocessed. This should help. Fred. >>> As this sounds to be a preprocessing issue, and to have a look to how >>> the code is preprocessed for Apple we can invert the two #ifdef >>> __APPLE__ condition of Olivier's patch to use the same preprocessor >>> commands on a Linux system. >>> >>> >>> Here is the code after having preprocessed it: >>> >>> >>> # 134 "include/common/initcall.h" >>> extern __attribute__((__weak__)) const struct initcall >>> *__start_init_STG_PREPARE __asm("section$start$__DATA$" STG_PREPARE); >>> extern __attribute__((__weak__)) const struct initcall >>> *__stop_init_STG_PREPARE __asm("section$end$__DATA$" STG_PREPARE); >>> extern __attribute__((__weak__)) const struct initcall >>> *__start_init_STG_LOCK __asm("section$start$__DATA$" STG_LOCK); extern >>> __attribute__((__weak__)) const struct initcall *__stop_init_STG_LOCK >>> __asm("section$end$__DATA$" STG_LOCK); >>> extern __attribute__((__weak__)) const struct initcall >>> *__start_init_STG_ALLOC __asm("section$start$__DATA$" STG_ALLOC); >>> extern __attribute__((__weak__)) const struct initcall >>> *__stop_init_STG_ALLOC __asm("section$end$__DATA$" STG_ALLOC); >>> extern __attribute__((__weak__)) const struct initcall >>> *__sta
Re: Early connection close, incomplete transfers
Am 14.02.2019 um 15:31 schrieb Veiko Kukk: > > On 2019-02-01 13:30, Veiko Kukk wrote: >> On 2019-02-01 12:34, Aleksandar Lazic wrote: >> >>> Do you have any errors in lighthttpds log? >> >> Yes, it has error messages about not being enable to write to socket. >> >> Unrecoverable error writing to socket! errno 32, retries 12, ppoll >> return 1, send return -1 >> ERROR: Couldn't write header data to socket! desired: 4565 / actual: -1 >> >> I've tested with several hundred thoused requests, but it never >> happens when using "mode tcp". > > Replaced HAproxy with Nginx for testing and with Nginx, not a single > connection > was interrupted, did millions of requests. In 1.9.4 are a lot of fixed added. please can you try your tests with 1.9.4, thanks. > Veiko Regards aleks
Re: Compilation fails on OS-X
Hi Patrick, On Thu, Feb 14, 2019 at 09:12:18AM -0500, Patrick Hemmer wrote: > > > On 2019/2/14 08:20, Frederic Lecaille wrote: > > On 2/14/19 1:32 PM, Frederic Lecaille wrote: > >> On 2/13/19 7:30 PM, Patrick Hemmer wrote: > >>> > >>> > >>> On 2019/2/13 10:29, Olivier Houchard wrote: > Hi Patrick, > > On Wed, Feb 13, 2019 at 10:01:01AM -0500, Patrick Hemmer wrote: > > On 2019/2/13 09:40, Aleksandar Lazic wrote: > >> Am 13.02.2019 um 14:45 schrieb Patrick Hemmer: > >>> Trying to compile haproxy on my local machine for testing > >>> purposes and am > >>> running into the following: > >> Which compiler do you use? > > # gcc -v > > Configured with: > > --prefix=/Applications/Xcode.app/Contents/Developer/usr > > --with-gxx-include-dir=/usr/include/c++/4.2.1 > > Apple LLVM version 9.0.0 (clang-900.0.39.2) > > Target: x86_64-apple-darwin17.7.0 > > Thread model: posix > > InstalledDir: > > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin > > > > > >>> # make TARGET=osx > >>> src/proto_http.c:293:1: error: argument to 'section' > >>> attribute is not > >>> valid for this target: mach-o section specifier requires a > >>> segment and section > >>> separated by a comma > >>> DECLARE_POOL(pool_head_http_txn, "http_txn", > >>> sizeof(struct http_txn)); > >>> ^ > >>> include/common/memory.h:128:2: note: expanded from > >>> macro 'DECLARE_POOL' > >>> REGISTER_POOL(&ptr, name, size) > >>> ^ > >>> include/common/memory.h:123:2: note: expanded from > >>> macro 'REGISTER_POOL' > >>> INITCALL3(STG_POOL, > >>> create_pool_callback, (ptr), (name), > >>> (size)) > >>> ^ > >>> include/common/initcall.h:102:2: note: expanded from > >>> macro 'INITCALL3' > >>> _DECLARE_INITCALL(stage, __LINE__, > >>> function, arg1, arg2, > >>> arg3) > >>> ^ > >>> include/common/initcall.h:78:2: note: expanded from macro > >>> '_DECLARE_INITCALL' > >>> __DECLARE_INITCALL(__VA_ARGS__) > >>> ^ > >>> include/common/initcall.h:65:42: note: expanded from macro > >>> '__DECLARE_INITCALL' > >>> __attribute__((__used__,__section__("init_"#stg))) = \ > >>> > >>> > >>> > >>> Issue occurs on master, and the 1.9 branch > >>> > >>> -Patrick > Does the (totally untested, because I have no Mac to test) patch > works for > you ? > >>> > >>> Unfortunately not. Just introduces a lot of new errors: > >>> > >>> > >>> In file included from src/ev_poll.c:22: > >>> In file included from include/common/hathreads.h:26: > >>> include/common/initcall.h:134:22: error: expected ')' > >>> DECLARE_INIT_SECTION(STG_PREPARE); > >>> ^ > >>> include/common/initcall.h:134:1: note: to match this '(' > >>> DECLARE_INIT_SECTION(STG_PREPARE); > >>> ^ > >>> include/common/initcall.h:124:82: note: expanded from macro > >>> 'DECLARE_INIT_SECTION' > >>> extern __attribute__((__weak__)) const struct > >>> initcall *__start_init_##stg __asm("section$start$__DATA$" stg); \ > >>> ^ > >> > >> Try to use -E in place of -c option of your compiler to stop after > >> having preprocessed the code. Then have a look to how the code of > >> src/ev_poll.c was preprocessed. > >> > >> This should help. > >> > >> Fred. > > > > As this sounds to be a preprocessing issue, and to have a look to how > > the code is preprocessed for Apple we can invert the two #ifdef > > __APPLE__ condition of Olivier's patch to use the same preprocessor > > commands on a Linux system. > > > > > > Here is the code after having preprocessed it: > > > > > > # 134 "include/common/initcall.h" > > extern __attribute__((__weak__)) const struct initcall > > *__start_init_STG_PREPARE __asm("section$start$__DATA$" STG_PREPARE); > > extern __attribute__((__weak__)) const struct initcall > > *__stop_init_STG_PREPARE __asm("section$end$__DATA$" STG_PREPARE); > > extern __attribute__((__weak__)) const struct initcall > > *__start_init_STG_LOCK __asm("section$start$__DATA$" STG_LOCK); extern > > __attribute__((__weak__)) const struct initcall *__stop_init_STG_LOCK > > __asm("section$end$__DATA$" STG_LOCK); > > extern __attribute__((__weak__)) const struct initcall > > *__start_init_STG_ALLOC __asm("section$start$__DATA$" STG_ALLOC); > > extern __attribute__((__weak__)) const struct initcall > > *__stop_init_STG_ALLOC __asm("section$end$__DATA$" STG_ALLOC); > > extern __attribute__((__weak__)) const struct initcall > > *__start_init_STG_POOL __asm("sect
Re: HAProxy with OpenSSL 1.1.1 breaks when TLS 1.3 KeyUpdate is used.
Hi Lukas, On Thu, Feb 14, 2019 at 06:28:29PM +0100, Lukas Tribus wrote: > Hello, > > > FYI the behavior was also changed on the openssl side (and will be in 1.1.1b): > https://github.com/openssl/openssl/commit/4af5836b55442f31795eff6c8c81ea7a1b8cf94b > > So applications fixes are only necessary for 1.1.1a. Cool, thanks for the heads up! Willy
Re: HAProxy with OpenSSL 1.1.1 breaks when TLS 1.3 KeyUpdate is used.
Hello, FYI the behavior was also changed on the openssl side (and will be in 1.1.1b): https://github.com/openssl/openssl/commit/4af5836b55442f31795eff6c8c81ea7a1b8cf94b So applications fixes are only necessary for 1.1.1a. Lukas
Re: Compilation fails on OS-X
Looks like apples llvm is not based on master branch. https://news.ycombinator.com/item?id=16545037 Ursprüngliche Nachricht Von: Frederic Lecaille Gesendet: 14. Februar 2019 16:13:01 MEZ An: Patrick Hemmer CC: Olivier Houchard , Aleksandar Lazic , haproxy@formilux.org Betreff: Re: Compilation fails on OS-X On 2/14/19 3:12 PM, Patrick Hemmer wrote: > > > On 2019/2/14 08:20, Frederic Lecaille wrote: >> On 2/14/19 1:32 PM, Frederic Lecaille wrote: >>> On 2/13/19 7:30 PM, Patrick Hemmer wrote: On 2019/2/13 10:29, Olivier Houchard wrote: > Hi Patrick, > > On Wed, Feb 13, 2019 at 10:01:01AM -0500, Patrick Hemmer wrote: >> On 2019/2/13 09:40, Aleksandar Lazic wrote: >>> Am 13.02.2019 um 14:45 schrieb Patrick Hemmer: Trying to compile haproxy on my local machine for testing purposes and am running into the following: >>> Which compiler do you use? >> # gcc -v >> Configured with: >> --prefix=/Applications/Xcode.app/Contents/Developer/usr >> --with-gxx-include-dir=/usr/include/c++/4.2.1 >> Apple LLVM version 9.0.0 (clang-900.0.39.2) >> Target: x86_64-apple-darwin17.7.0 >> Thread model: posix >> InstalledDir: >> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin >> >> >> # make TARGET=osx src/proto_http.c:293:1: error: argument to 'section' attribute is not valid for this target: mach-o section specifier requires a segment and section separated by a comma DECLARE_POOL(pool_head_http_txn, "http_txn", sizeof(struct http_txn)); ^ include/common/memory.h:128:2: note: expanded from macro 'DECLARE_POOL' REGISTER_POOL(&ptr, name, size) ^ include/common/memory.h:123:2: note: expanded from macro 'REGISTER_POOL' INITCALL3(STG_POOL, create_pool_callback, (ptr), (name), (size)) ^ include/common/initcall.h:102:2: note: expanded from macro 'INITCALL3' _DECLARE_INITCALL(stage, __LINE__, function, arg1, arg2, arg3) ^ include/common/initcall.h:78:2: note: expanded from macro '_DECLARE_INITCALL' __DECLARE_INITCALL(__VA_ARGS__) ^ include/common/initcall.h:65:42: note: expanded from macro '__DECLARE_INITCALL' __attribute__((__used__,__section__("init_"#stg))) = \ Issue occurs on master, and the 1.9 branch -Patrick > Does the (totally untested, because I have no Mac to test) patch > works for > you ? Unfortunately not. Just introduces a lot of new errors: In file included from src/ev_poll.c:22: In file included from include/common/hathreads.h:26: include/common/initcall.h:134:22: error: expected ')' DECLARE_INIT_SECTION(STG_PREPARE); ^ include/common/initcall.h:134:1: note: to match this '(' DECLARE_INIT_SECTION(STG_PREPARE); ^ include/common/initcall.h:124:82: note: expanded from macro 'DECLARE_INIT_SECTION' extern __attribute__((__weak__)) const struct initcall *__start_init_##stg __asm("section$start$__DATA$" stg); \ ^ >>> >>> Try to use -E in place of -c option of your compiler to stop after >>> having preprocessed the code. Then have a look to how the code of >>> src/ev_poll.c was preprocessed. >>> >>> This should help. >>> >>> Fred. >> >> As this sounds to be a preprocessing issue, and to have a look to how >> the code is preprocessed for Apple we can invert the two #ifdef >> __APPLE__ condition of Olivier's patch to use the same preprocessor >> commands on a Linux system. >> >> >> Here is the code after having preprocessed it: >> >> >> # 134 "include/common/initcall.h" >> extern __attribute__((__weak__)) const struct initcall >> *__start_init_STG_PREPARE __asm("section$start$__DATA$" STG_PREPARE); >> extern __attribute__((__weak__)) const struct initcall >> *__stop_init_STG_PREPARE __asm("section$end$__DATA$" STG_PREPARE); >> extern __attribute__((__weak__)) const struct initcall >> *__start_init_STG_LOCK __asm("section$start$__DATA$" STG_LOCK); extern >> __attribute__((__weak__)) const struct initcall *__stop_init_STG_LOCK >> __asm("section$end$__DATA$" STG_LOCK); >> extern __attribute__((__weak__)) const struct initcall >> *__start_init_STG_ALLOC __asm("section$start$__DATA$" STG_ALLOC); >> extern __attribute__((__
Re: Compilation fails on OS-X
On 2/14/19 3:12 PM, Patrick Hemmer wrote: On 2019/2/14 08:20, Frederic Lecaille wrote: On 2/14/19 1:32 PM, Frederic Lecaille wrote: On 2/13/19 7:30 PM, Patrick Hemmer wrote: On 2019/2/13 10:29, Olivier Houchard wrote: Hi Patrick, On Wed, Feb 13, 2019 at 10:01:01AM -0500, Patrick Hemmer wrote: On 2019/2/13 09:40, Aleksandar Lazic wrote: Am 13.02.2019 um 14:45 schrieb Patrick Hemmer: Trying to compile haproxy on my local machine for testing purposes and am running into the following: Which compiler do you use? # gcc -v Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1 Apple LLVM version 9.0.0 (clang-900.0.39.2) Target: x86_64-apple-darwin17.7.0 Thread model: posix InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin # make TARGET=osx src/proto_http.c:293:1: error: argument to 'section' attribute is not valid for this target: mach-o section specifier requires a segment and section separated by a comma DECLARE_POOL(pool_head_http_txn, "http_txn", sizeof(struct http_txn)); ^ include/common/memory.h:128:2: note: expanded from macro 'DECLARE_POOL' REGISTER_POOL(&ptr, name, size) ^ include/common/memory.h:123:2: note: expanded from macro 'REGISTER_POOL' INITCALL3(STG_POOL, create_pool_callback, (ptr), (name), (size)) ^ include/common/initcall.h:102:2: note: expanded from macro 'INITCALL3' _DECLARE_INITCALL(stage, __LINE__, function, arg1, arg2, arg3) ^ include/common/initcall.h:78:2: note: expanded from macro '_DECLARE_INITCALL' __DECLARE_INITCALL(__VA_ARGS__) ^ include/common/initcall.h:65:42: note: expanded from macro '__DECLARE_INITCALL' __attribute__((__used__,__section__("init_"#stg))) = \ Issue occurs on master, and the 1.9 branch -Patrick Does the (totally untested, because I have no Mac to test) patch works for you ? Unfortunately not. Just introduces a lot of new errors: In file included from src/ev_poll.c:22: In file included from include/common/hathreads.h:26: include/common/initcall.h:134:22: error: expected ')' DECLARE_INIT_SECTION(STG_PREPARE); ^ include/common/initcall.h:134:1: note: to match this '(' DECLARE_INIT_SECTION(STG_PREPARE); ^ include/common/initcall.h:124:82: note: expanded from macro 'DECLARE_INIT_SECTION' extern __attribute__((__weak__)) const struct initcall *__start_init_##stg __asm("section$start$__DATA$" stg); \ ^ Try to use -E in place of -c option of your compiler to stop after having preprocessed the code. Then have a look to how the code of src/ev_poll.c was preprocessed. This should help. Fred. As this sounds to be a preprocessing issue, and to have a look to how the code is preprocessed for Apple we can invert the two #ifdef __APPLE__ condition of Olivier's patch to use the same preprocessor commands on a Linux system. Here is the code after having preprocessed it: # 134 "include/common/initcall.h" extern __attribute__((__weak__)) const struct initcall *__start_init_STG_PREPARE __asm("section$start$__DATA$" STG_PREPARE); extern __attribute__((__weak__)) const struct initcall *__stop_init_STG_PREPARE __asm("section$end$__DATA$" STG_PREPARE); extern __attribute__((__weak__)) const struct initcall *__start_init_STG_LOCK __asm("section$start$__DATA$" STG_LOCK); extern __attribute__((__weak__)) const struct initcall *__stop_init_STG_LOCK __asm("section$end$__DATA$" STG_LOCK); extern __attribute__((__weak__)) const struct initcall *__start_init_STG_ALLOC __asm("section$start$__DATA$" STG_ALLOC); extern __attribute__((__weak__)) const struct initcall *__stop_init_STG_ALLOC __asm("section$end$__DATA$" STG_ALLOC); extern __attribute__((__weak__)) const struct initcall *__start_init_STG_POOL __asm("section$start$__DATA$" STG_POOL); extern __attribute__((__weak__)) const struct initcall *__stop_init_STG_POOL __asm("section$end$__DATA$" STG_POOL); extern __attribute__((__weak__)) const struct initcall *__start_init_STG_REGISTER __asm("section$start$__DATA$" STG_REGISTER); extern __attribute__((__weak__)) const struct initcall *__stop_init_STG_REGISTER __asm("section$end$__DATA$" STG_REGISTER); extern __attribute__((__weak__)) const struct initcall *__start_init_STG_INIT __asm("section$start$__DATA$" STG_INIT); extern __attribute__((__weak__)) const struct initcall *__stop_init_STG_INIT __asm("section$end$__DATA$" STG_INIT); should be I guess extern __attribute__((__weak__)) const struct initcall *__start_init_STG_PREPARE __asm("section$start$__DATA$STG_PREPARE"); etc. and the compiler warns like t
Re: Early connection close, incomplete transfers
On 2019-02-01 13:30, Veiko Kukk wrote: On 2019-02-01 12:34, Aleksandar Lazic wrote: Do you have any errors in lighthttpds log? Yes, it has error messages about not being enable to write to socket. Unrecoverable error writing to socket! errno 32, retries 12, ppoll return 1, send return -1 ERROR: Couldn't write header data to socket! desired: 4565 / actual: -1 I've tested with several hundred thoused requests, but it never happens when using "mode tcp". Replaced HAproxy with Nginx for testing and with Nginx, not a single connection was interrupted, did millions of requests. Veiko
Re: Compilation fails on OS-X
On 2019/2/14 08:20, Frederic Lecaille wrote: > On 2/14/19 1:32 PM, Frederic Lecaille wrote: >> On 2/13/19 7:30 PM, Patrick Hemmer wrote: >>> >>> >>> On 2019/2/13 10:29, Olivier Houchard wrote: Hi Patrick, On Wed, Feb 13, 2019 at 10:01:01AM -0500, Patrick Hemmer wrote: > On 2019/2/13 09:40, Aleksandar Lazic wrote: >> Am 13.02.2019 um 14:45 schrieb Patrick Hemmer: >>> Trying to compile haproxy on my local machine for testing >>> purposes and am >>> running into the following: >> Which compiler do you use? > # gcc -v > Configured with: > --prefix=/Applications/Xcode.app/Contents/Developer/usr > --with-gxx-include-dir=/usr/include/c++/4.2.1 > Apple LLVM version 9.0.0 (clang-900.0.39.2) > Target: x86_64-apple-darwin17.7.0 > Thread model: posix > InstalledDir: > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin > > >>> # make TARGET=osx >>> src/proto_http.c:293:1: error: argument to 'section' >>> attribute is not >>> valid for this target: mach-o section specifier requires a >>> segment and section >>> separated by a comma >>> DECLARE_POOL(pool_head_http_txn, "http_txn", >>> sizeof(struct http_txn)); >>> ^ >>> include/common/memory.h:128:2: note: expanded from >>> macro 'DECLARE_POOL' >>> REGISTER_POOL(&ptr, name, size) >>> ^ >>> include/common/memory.h:123:2: note: expanded from >>> macro 'REGISTER_POOL' >>> INITCALL3(STG_POOL, >>> create_pool_callback, (ptr), (name), >>> (size)) >>> ^ >>> include/common/initcall.h:102:2: note: expanded from >>> macro 'INITCALL3' >>> _DECLARE_INITCALL(stage, __LINE__, >>> function, arg1, arg2, >>> arg3) >>> ^ >>> include/common/initcall.h:78:2: note: expanded from macro >>> '_DECLARE_INITCALL' >>> __DECLARE_INITCALL(__VA_ARGS__) >>> ^ >>> include/common/initcall.h:65:42: note: expanded from macro >>> '__DECLARE_INITCALL' >>> __attribute__((__used__,__section__("init_"#stg))) = \ >>> >>> >>> >>> Issue occurs on master, and the 1.9 branch >>> >>> -Patrick Does the (totally untested, because I have no Mac to test) patch works for you ? >>> >>> Unfortunately not. Just introduces a lot of new errors: >>> >>> >>> In file included from src/ev_poll.c:22: >>> In file included from include/common/hathreads.h:26: >>> include/common/initcall.h:134:22: error: expected ')' >>> DECLARE_INIT_SECTION(STG_PREPARE); >>> ^ >>> include/common/initcall.h:134:1: note: to match this '(' >>> DECLARE_INIT_SECTION(STG_PREPARE); >>> ^ >>> include/common/initcall.h:124:82: note: expanded from macro >>> 'DECLARE_INIT_SECTION' >>> extern __attribute__((__weak__)) const struct >>> initcall *__start_init_##stg __asm("section$start$__DATA$" stg); \ >>> ^ >> >> Try to use -E in place of -c option of your compiler to stop after >> having preprocessed the code. Then have a look to how the code of >> src/ev_poll.c was preprocessed. >> >> This should help. >> >> Fred. > > As this sounds to be a preprocessing issue, and to have a look to how > the code is preprocessed for Apple we can invert the two #ifdef > __APPLE__ condition of Olivier's patch to use the same preprocessor > commands on a Linux system. > > > Here is the code after having preprocessed it: > > > # 134 "include/common/initcall.h" > extern __attribute__((__weak__)) const struct initcall > *__start_init_STG_PREPARE __asm("section$start$__DATA$" STG_PREPARE); > extern __attribute__((__weak__)) const struct initcall > *__stop_init_STG_PREPARE __asm("section$end$__DATA$" STG_PREPARE); > extern __attribute__((__weak__)) const struct initcall > *__start_init_STG_LOCK __asm("section$start$__DATA$" STG_LOCK); extern > __attribute__((__weak__)) const struct initcall *__stop_init_STG_LOCK > __asm("section$end$__DATA$" STG_LOCK); > extern __attribute__((__weak__)) const struct initcall > *__start_init_STG_ALLOC __asm("section$start$__DATA$" STG_ALLOC); > extern __attribute__((__weak__)) const struct initcall > *__stop_init_STG_ALLOC __asm("section$end$__DATA$" STG_ALLOC); > extern __attribute__((__weak__)) const struct initcall > *__start_init_STG_POOL __asm("section$start$__DATA$" STG_POOL); extern > __attribute__((__weak__)) const struct initcall *__stop_init_STG_POOL > __asm("section$end$__DATA$" STG_POOL); > extern __attribute__((__weak__)) const struct initcall > *__start_init_STG_REGISTER __asm("section$start$__DATA$" > STG_REGISTER); extern __attribute__((__weak__))
Re: Compilation fails on OS-X
On 2/14/19 1:32 PM, Frederic Lecaille wrote: On 2/13/19 7:30 PM, Patrick Hemmer wrote: On 2019/2/13 10:29, Olivier Houchard wrote: Hi Patrick, On Wed, Feb 13, 2019 at 10:01:01AM -0500, Patrick Hemmer wrote: On 2019/2/13 09:40, Aleksandar Lazic wrote: Am 13.02.2019 um 14:45 schrieb Patrick Hemmer: Trying to compile haproxy on my local machine for testing purposes and am running into the following: Which compiler do you use? # gcc -v Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1 Apple LLVM version 9.0.0 (clang-900.0.39.2) Target: x86_64-apple-darwin17.7.0 Thread model: posix InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin # make TARGET=osx src/proto_http.c:293:1: error: argument to 'section' attribute is not valid for this target: mach-o section specifier requires a segment and section separated by a comma DECLARE_POOL(pool_head_http_txn, "http_txn", sizeof(struct http_txn)); ^ include/common/memory.h:128:2: note: expanded from macro 'DECLARE_POOL' REGISTER_POOL(&ptr, name, size) ^ include/common/memory.h:123:2: note: expanded from macro 'REGISTER_POOL' INITCALL3(STG_POOL, create_pool_callback, (ptr), (name), (size)) ^ include/common/initcall.h:102:2: note: expanded from macro 'INITCALL3' _DECLARE_INITCALL(stage, __LINE__, function, arg1, arg2, arg3) ^ include/common/initcall.h:78:2: note: expanded from macro '_DECLARE_INITCALL' __DECLARE_INITCALL(__VA_ARGS__) ^ include/common/initcall.h:65:42: note: expanded from macro '__DECLARE_INITCALL' __attribute__((__used__,__section__("init_"#stg))) = \ Issue occurs on master, and the 1.9 branch -Patrick Does the (totally untested, because I have no Mac to test) patch works for you ? Unfortunately not. Just introduces a lot of new errors: In file included from src/ev_poll.c:22: In file included from include/common/hathreads.h:26: include/common/initcall.h:134:22: error: expected ')' DECLARE_INIT_SECTION(STG_PREPARE); ^ include/common/initcall.h:134:1: note: to match this '(' DECLARE_INIT_SECTION(STG_PREPARE); ^ include/common/initcall.h:124:82: note: expanded from macro 'DECLARE_INIT_SECTION' extern __attribute__((__weak__)) const struct initcall *__start_init_##stg __asm("section$start$__DATA$" stg); \ ^ Try to use -E in place of -c option of your compiler to stop after having preprocessed the code. Then have a look to how the code of src/ev_poll.c was preprocessed. This should help. Fred. As this sounds to be a preprocessing issue, and to have a look to how the code is preprocessed for Apple we can invert the two #ifdef __APPLE__ condition of Olivier's patch to use the same preprocessor commands on a Linux system. Here is the code after having preprocessed it: # 134 "include/common/initcall.h" extern __attribute__((__weak__)) const struct initcall *__start_init_STG_PREPARE __asm("section$start$__DATA$" STG_PREPARE); extern __attribute__((__weak__)) const struct initcall *__stop_init_STG_PREPARE __asm("section$end$__DATA$" STG_PREPARE); extern __attribute__((__weak__)) const struct initcall *__start_init_STG_LOCK __asm("section$start$__DATA$" STG_LOCK); extern __attribute__((__weak__)) const struct initcall *__stop_init_STG_LOCK __asm("section$end$__DATA$" STG_LOCK); extern __attribute__((__weak__)) const struct initcall *__start_init_STG_ALLOC __asm("section$start$__DATA$" STG_ALLOC); extern __attribute__((__weak__)) const struct initcall *__stop_init_STG_ALLOC __asm("section$end$__DATA$" STG_ALLOC); extern __attribute__((__weak__)) const struct initcall *__start_init_STG_POOL __asm("section$start$__DATA$" STG_POOL); extern __attribute__((__weak__)) const struct initcall *__stop_init_STG_POOL __asm("section$end$__DATA$" STG_POOL); extern __attribute__((__weak__)) const struct initcall *__start_init_STG_REGISTER __asm("section$start$__DATA$" STG_REGISTER); extern __attribute__((__weak__)) const struct initcall *__stop_init_STG_REGISTER __asm("section$end$__DATA$" STG_REGISTER); extern __attribute__((__weak__)) const struct initcall *__start_init_STG_INIT __asm("section$start$__DATA$" STG_INIT); extern __attribute__((__weak__)) const struct initcall *__stop_init_STG_INIT __asm("section$end$__DATA$" STG_INIT); should be I guess extern __attribute__((__weak__)) const struct initcall *__start_init_STG_PREPARE __asm("section$start$__DATA$STG_PREPARE"); etc. and the compiler warns like this: $ gcc -Iinclude -Iebtree -Wall -Wextra -O2 -g -fno-stric
Re: Compilation fails on OS-X
On 2/13/19 7:30 PM, Patrick Hemmer wrote: On 2019/2/13 10:29, Olivier Houchard wrote: Hi Patrick, On Wed, Feb 13, 2019 at 10:01:01AM -0500, Patrick Hemmer wrote: On 2019/2/13 09:40, Aleksandar Lazic wrote: Am 13.02.2019 um 14:45 schrieb Patrick Hemmer: Trying to compile haproxy on my local machine for testing purposes and am running into the following: Which compiler do you use? # gcc -v Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1 Apple LLVM version 9.0.0 (clang-900.0.39.2) Target: x86_64-apple-darwin17.7.0 Thread model: posix InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin # make TARGET=osx src/proto_http.c:293:1: error: argument to 'section' attribute is not valid for this target: mach-o section specifier requires a segment and section separated by a comma DECLARE_POOL(pool_head_http_txn, "http_txn", sizeof(struct http_txn)); ^ include/common/memory.h:128:2: note: expanded from macro 'DECLARE_POOL' REGISTER_POOL(&ptr, name, size) ^ include/common/memory.h:123:2: note: expanded from macro 'REGISTER_POOL' INITCALL3(STG_POOL, create_pool_callback, (ptr), (name), (size)) ^ include/common/initcall.h:102:2: note: expanded from macro 'INITCALL3' _DECLARE_INITCALL(stage, __LINE__, function, arg1, arg2, arg3) ^ include/common/initcall.h:78:2: note: expanded from macro '_DECLARE_INITCALL' __DECLARE_INITCALL(__VA_ARGS__) ^ include/common/initcall.h:65:42: note: expanded from macro '__DECLARE_INITCALL' __attribute__((__used__,__section__("init_"#stg))) = \ Issue occurs on master, and the 1.9 branch -Patrick Does the (totally untested, because I have no Mac to test) patch works for you ? Unfortunately not. Just introduces a lot of new errors: In file included from src/ev_poll.c:22: In file included from include/common/hathreads.h:26: include/common/initcall.h:134:22: error: expected ')' DECLARE_INIT_SECTION(STG_PREPARE); ^ include/common/initcall.h:134:1: note: to match this '(' DECLARE_INIT_SECTION(STG_PREPARE); ^ include/common/initcall.h:124:82: note: expanded from macro 'DECLARE_INIT_SECTION' extern __attribute__((__weak__)) const struct initcall *__start_init_##stg __asm("section$start$__DATA$" stg); \ ^ Try to use -E in place of -c option of your compiler to stop after having preprocessed the code. Then have a look to how the code of src/ev_poll.c was preprocessed. This should help. Fred.
Re: [RFC PATCH] MEDIUM: compression: Add support for brotli compression
Aleks, Am 14.02.19 um 12:00 schrieb Aleksandar Lazic: >> I am successfully able access brotli compressed URLs with Google Chrome, >> this requires me to disable `gzip` though (because haproxy prefers to >> select gzip, I suspect because `br` is last in Chrome's `Accept-Encoding` >> header). > > Does it change it when you use `br` as frist entry in `compression algo ... ` > > https://cbonte.github.io/haproxy-dconv/1.9/configuration.html#4.2-compression%20algo I tried that. It does not. In the absence of a q-value for the encoding HAProxy select the first value listed in the Accept-Encoding header. I just checked RFC 7231#section-5.3.4 which does not specify a priority in this case. Maybe the code should be changed to use order of the algorithms in the config to determine the priority when the client gives equal priorities. >> I also am able to sucessfully download and decompress URLs with `curl` >> and the `brotli` CLI utility. The server I use as the backend for these >> tests has about 45ms RTT to my machine. The HTML page I use is some random >> HTML page on the server, the noise file is 1 MiB of finest /dev/urandom. >> >> You'll notice that brotli compressed requests are both faster as well as >> smaller compared to gzip with the hardcoded brotli compression quality >> of 3. The default is 11, which is *way* slower than gzip. > > How much more/less/equal CPU usage have brotli compared to gzip? I did not check, because I would have to build something more elaborate than "look at curl's output" for that. Also I have no idea how I would do so. I'll leave this up to the experts :-) > I'm a little bit disappointed from the size point of view, it is only ~6K less > then gzip, is it worth the amount of work for such a small gain of data > reduction. Even 6kB add up over time. Especially on cellular networks. Also I did not tune all the brotli encoder knobs yet. As an example one could specify that the contents is UTF-8 encoded text which possibly improves compression rate further (I guess it selects a different dictionary): https://github.com/google/brotli/blob/5805f99a533a8f8118699c0100d8c102f3605f65/docs/encode.h.3#L197-L204 Best regards Tim Düsterhus
Re: [RFC PATCH] MEDIUM: compression: Add support for brotli compression
Hi Tim. Am 13.02.2019 um 17:57 schrieb Tim Duesterhus: > Willy, > Aleks, > List, > > this (absolutely non-ready-to-merge) patch adds support for brotli > compression as suggested in issue #21: > https://github.com/haproxy/haproxy/issues/21 Cool ;-) > It is tested on Ubuntu Xenial with libbrotli 1.0.3: > > [timwolla@~]apt-cache policy libbrotli-dev > libbrotli-dev: > Installed: 1.0.3-1ubuntu1~16.04.1 > Candidate: 1.0.3-1ubuntu1~16.04.1 > Version table: > *** 1.0.3-1ubuntu1~16.04.1 500 > 500 http://de.archive.ubuntu.com/ubuntu xenial-updates/main > amd64 Packages > 100 /var/lib/dpkg/status > [timwolla@~]apt-cache policy libbrotli1 > libbrotli1: > Installed: 1.0.3-1ubuntu1~16.04.1 > Candidate: 1.0.3-1ubuntu1~16.04.1 > Version table: > *** 1.0.3-1ubuntu1~16.04.1 500 > 500 http://de.archive.ubuntu.com/ubuntu xenial-updates/main > amd64 Packages > 100 /var/lib/dpkg/status > > I am successfully able access brotli compressed URLs with Google Chrome, > this requires me to disable `gzip` though (because haproxy prefers to > select gzip, I suspect because `br` is last in Chrome's `Accept-Encoding` > header). Does it change it when you use `br` as frist entry in `compression algo ... ` https://cbonte.github.io/haproxy-dconv/1.9/configuration.html#4.2-compression%20algo > I also am able to sucessfully download and decompress URLs with `curl` > and the `brotli` CLI utility. The server I use as the backend for these > tests has about 45ms RTT to my machine. The HTML page I use is some random > HTML page on the server, the noise file is 1 MiB of finest /dev/urandom. > > You'll notice that brotli compressed requests are both faster as well as > smaller compared to gzip with the hardcoded brotli compression quality > of 3. The default is 11, which is *way* slower than gzip. How much more/less/equal CPU usage have brotli compared to gzip? I'm a little bit disappointed from the size point of view, it is only ~6K less then gzip, is it worth the amount of work for such a small gain of data reduction. Regards Aleks > + curl localhost:8080/*snip*.html -H 'Accept-Encoding: gzip' > % Total% Received % Xferd Average Speed TimeTime Time > Current > Dload Upload Total SpentLeft > Speed > 100 492800 492800 0 279k 0 --:--:-- --:--:-- > --:--:-- 279k > + curl localhost:8080/*snip*.html -H 'Accept-Encoding: br' > % Total% Received % Xferd Average Speed TimeTime Time > Current > Dload Upload Total SpentLeft > Speed > 100 434010 434010 0 332k 0 --:--:-- --:--:-- > --:--:-- 333k > + curl localhost:8080/*snip*.html -H 'Accept-Encoding: identity' > % Total% Received % Xferd Average Speed TimeTime Time > Current > Dload Upload Total SpentLeft > Speed > 100 127k 100 127k0 0 441k 0 --:--:-- --:--:-- > --:--:-- 441k > + curl localhost:8080/noise -H 'Accept-Encoding: gzip' > % Total% Received % Xferd Average Speed TimeTime Time > Current > Dload Upload Total SpentLeft > Speed > 100 1025k0 1025k0 0 3330k 0 --:--:-- --:--:-- > --:--:-- 3338k > + curl localhost:8080/noise -H 'Accept-Encoding: br' > % Total% Received % Xferd Average Speed TimeTime Time > Current > Dload Upload Total SpentLeft > Speed > 100 1024k0 1024k0 0 3029k 0 --:--:-- --:--:-- > --:--:-- 3030k > + curl localhost:8080/noise -H 'Accept-Encoding: identity' > % Total% Received % Xferd Average Speed TimeTime Time > Current > Dload Upload Total SpentLeft > Speed > 100 1024k 100 1024k0 0 3003k 0 --:--:-- --:--:-- > --:--:-- 3002k > + ls -al > total 3384 > drwxrwxr-x 2 timwolla timwolla4096 Feb 13 17:30 . > drwxrwxrwt 28 root root 69632 Feb 13 17:25 .. > -rw-rw-r-- 1 timwolla timwolla 598 Feb 13 17:30 download > -rw-rw-r-- 1 timwolla timwolla 43401 Feb 13 17:30 html-br > -rw-rw-r-- 1 timwolla timwolla 49280 Feb 13 17:30 html-gz > -rw-rw-r-- 1 timwolla timwolla 130334 Feb 13 17:30 html-id > -rw-rw-r-- 1 timwolla timwolla 1048949 Feb 13 17:30 noise-br > -rw-rw-r-- 1 timwolla timwolla 1049666 Feb 13 17:30 noise-gz > -rw-rw-r-- 1 timwolla timwolla 1048576 Feb 13 17:30 noise-id > ++ zcat html-gz > + sha256sum html-id /dev/fd/63 /dev/fd/62 > ++ brotli --decompress --stdout html-br > 56f1664241b3dbb750f93b69570be76c6baccb8de4f
HAProxy incase of dynamic backends
Hi, In our kubernetes environment, we have dynamic backend services/pods (servers) and looking for a way in HAProxy config to resolve it through DNS resolver config by using SNI- FQDN. Attempted below config, which parse fails due to '%[req.ssl_sni]' in 'server' entry. Appreciate your inputs on how this could be achieved. defaults log global timeout client 50s timeout client-fin 50s timeout connect 5s timeout server 10s timeout tunnel 50s resolvers dns nameserver private-0 192.0.2.1:53 hold valid 1s listen tcp-0_0_0_0-443 bind *:443 mode tcp tcp-request inspect-delay 5s tcp-request content accept if { req_ssl_hello_type 1 } server services %[req.ssl_sni]:443 check resolvers dns resolve-prefer ipv4 check thanks, raj +918067153382