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(, 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
>>>
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(, 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
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(, 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
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(, 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
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(, 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(, 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
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(, 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 >
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
