001
From: Miroslav Zagorac
Date: Wed, 9 Mar 2022 19:59:15 +0100
Subject: [PATCH 16/16] BUG/BUILD: opentracing: fixed OT_DEFINE variable
setting
In case of using parameter 'OT_USE_VARS=1', the value of the OT_DEFINE
variable is set incorrectly (i.e. the previous value was deleted and a
new one
18:42:54 +0100
Subject: [PATCH 06/16] BUG/MINOR: opentracing: setting the return value in
function flt_ot_var_set()
Function flt_ot_var_set() did not check whether the variable was
successfully set or not. In case of failure, the value -1 is returned.
---
addons/ot/src/vars.c | 8 +++-
1 f
Jarno,
On 3/30/22 14:57, Jarno Huuskonen wrote:
Hello,
when testing with HTTP/2 we found a behaviour, we did not expect:
we use switching between different backends by use of a map file, e.g.:
use_backend %[url,map_beg(/etc/haproxy/pool.map,defaultbackend)]
With HTTP/1.1 this works
Hi,
On Wed, 2022-03-30 at 12:19 +, Ralf Saier wrote:
> Hello,
>
> when testing with HTTP/2 we found a behaviour, we did not expect:
>
> we use switching between different backends by use of a map file, e.g.:
> use_backend %[url,map_beg(/etc/haproxy/pool.map,defaultbackend)]
>
> With
Hello,
when testing with HTTP/2 we found a behaviour, we did not expect:
we use switching between different backends by use of a map file, e.g.:
use_backend %[url,map_beg(/etc/haproxy/pool.map,defaultbackend)]
With HTTP/1.1 this works fine in haproxy.
But with HTTP/2, it does not work.
Here's
Hi all
On 3/6/22 18:10, Dhruv Jain wrote:
I would request you to share a work around if possible until it is fixed.
As a heads up: There's an issue in the tracker now. So before replying
you might want to check there first:
https://github.com/haproxy/haproxy/issues/1598
Best regards
Tim
Dhruv,
On 3/6/22 18:10, Dhruv Jain wrote:
In the following mqtt connection flow, mqtt_is_valid and mqtt_field_value
is not working as intended.
Client -> Google Load Balancer(proxy-protocol enabled) -> HAProxy
Currently the connection is rejected if the ACL rule(
Hi,
In the following mqtt connection flow, mqtt_is_valid and mqtt_field_value
is not working as intended.
Client -> Google Load Balancer(proxy-protocol enabled) -> HAProxy
Currently the connection is rejected if the ACL rule(
https://pastebin.mozilla.org/TESFMj1b#L57) is mentioned in the
On Thu, Feb 17, 2022 at 03:40:51PM +0100, Lukas Tribus wrote:
> As per issue #1552 the mailer code currently breaks on ESMTP multiline
> responses. Let's negotiate SMTP instead.
Merged, thank you Lukas!
Willy
As per issue #1552 the mailer code currently breaks on ESMTP multiline
responses. Let's negotiate SMTP instead.
Should be backported to 2.0.
---
src/mailers.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mailers.c b/src/mailers.c
index 3d01d7532..34eaa5bb6 100644
---
On Wed, Jan 19, 2022 at 03:32:35PM +0100, Willy Tarreau wrote:
> Subject: Re: [PATCH] BUG/MEDIUM: server: avoid changing healthcheck ctx with
> set server ssl
>
> On Wed, Jan 19, 2022 at 03:24:44PM +0100, William Lallemand wrote:
> > On Tue, Jan 18, 2022 at 12:07:21PM +0100, W
On Wed, Jan 19, 2022 at 03:24:44PM +0100, William Lallemand wrote:
> On Tue, Jan 18, 2022 at 12:07:21PM +0100, Willy Tarreau wrote:
> >
> > On Mon, Jan 17, 2022 at 07:46:24PM +0100, William Dauchy wrote:
> > > Hello Christopher,
> > >
> > > On Wed, Jan 12, 2022 at 12:45 PM William Dauchy wrote:
On Tue, Jan 18, 2022 at 12:07:21PM +0100, Willy Tarreau wrote:
>
> On Mon, Jan 17, 2022 at 07:46:24PM +0100, William Dauchy wrote:
> > Hello Christopher,
> >
> > On Wed, Jan 12, 2022 at 12:45 PM William Dauchy wrote:
> > > my approach was to say:
> > > - remove the implicit behavior
> > > - then
On Mon, Jan 17, 2022 at 07:46:24PM +0100, William Dauchy wrote:
> Hello Christopher,
>
> On Wed, Jan 12, 2022 at 12:45 PM William Dauchy wrote:
> > my approach was to say:
> > - remove the implicit behavior
> > - then work on the missing commands for the health checks
>
> Do you think we can
Hello Christopher,
On Wed, Jan 12, 2022 at 12:45 PM William Dauchy wrote:
> my approach was to say:
> - remove the implicit behavior
> - then work on the missing commands for the health checks
Do you think we can conclude on it?
--
William
On Wed, Jan 12, 2022 at 10:02 AM Christopher Faulet wrote:
> I don't know what is the expected behavior on the stable releases for users.
> Honestly, I've misread you patch and kept in mind you alternative solution...
> But as said, if there is no implicit change (and I'm fine with this
>
On Wed, Jan 12, 2022 at 10:02:30AM +0100, Christopher Faulet wrote:
> I don't know what is the expected behavior on the stable releases for users.
> The actual state is buggy because health-check are only updated when ssl is
> disabled. When SSL is enabled on a server, there is no implicit change
be different because of implicit changes and it is
> pretty hard to predict how it will behave in all cases.
> For instance, to fix William's bug about "set server ssl" command, in a way
> or another, we must stop to dynamically update the health-check if its port
> or its ad
Le 1/11/22 à 22:47, William Dauchy a écrit :
Agree. But, if possible, a warning may be added in the documentation to warn
about implicit changes.
From the discussion, I would be tempted to say the opposite, as I feel
like keeping implicit things for this command is worse.
I don't know what
ng the order of
> commands, the result can be different because of implicit changes and it is
> pretty hard to predict how it will behave in all cases.
yup totally agree with both of you. I can't really remember why I did
that in the first place.
> For instance, to fix William's bug ab
Willy on this point. Especially because, depending the order of
commands, the result can be different because of implicit changes and it is
pretty hard to predict how it will behave in all cases.
For instance, to fix William's bug about "set server ssl" command, in a way or
anothe
Le 1/10/22 à 23:19, Willy Tarreau a écrit :
w options were still configurable on the CLI by then.
"check-ssl" has been available for a long time, so that's not the
reason behind it, but I guess you were referring to something else. I
suspect I did a dumb copy/paste from the new_server function
sl` in your default server. In that sense I believe
> it should be backported to v2.4.
If you're *certain* that we're not going to break existing 2.4
deployments that could rely on the current behavior, I'm fine with that.
It's just that I absolutely hate behavior changes in stable versions
because we tend to think we've seen all corner cases, and after a
release someone reports an issue :-/ I can't think of a case which
would benefit from the current bug, I'm just trying to be careful.
Thanks!
Willy
On Sat, Jan 8, 2022 at 3:03 PM Tim Düsterhus wrote:
> Causes issues when applying the patch, because git gets confused and
> believes this to be the patch.
> I tend to indent this type of "literal code block" within my commit
> message with 4 spaces for clarity.
indeed, good point, will fix if I
On Thu, Jan 06, 2022 at 04:57:15PM +0100, William Dauchy wrote:
> While giving a fresh try to `set server ssl` (which I wrote), I realised
> the behavior is a bit inconsistent. Indeed when using this command over
> a server with ssl enabled for the data path but also for the health
> check path we
William,
as a heads up, this part of the commit message:
On 1/6/22 4:57 PM, William Dauchy wrote:
The alternative solution was to restore the previous state, but I
believe this will create even more confusion in the future:
--- a/src/server.c
+++ b/src/server.c
@@ -2113,8 +2113,11 @@ void
While giving a fresh try to `set server ssl` (which I wrote), I realised
the behavior is a bit inconsistent. Indeed when using this command over
a server with ssl enabled for the data path but also for the health
check path we have:
- data and health check done using tls
- emit `set server
Le 12/1/21 à 23:04, Tim Duesterhus a écrit :
The function leaked one full buffer per invocation. Fix this by simply removing
the call to alloc_trash_chunk(), the static chunk from get_trash_chunk() is
sufficient.
This bug was introduced in 0a72f5ee7c2a61bdb379436461269315c776b50a, which is
2.5
The function leaked one full buffer per invocation. Fix this by simply removing
the call to alloc_trash_chunk(), the static chunk from get_trash_chunk() is
sufficient.
This bug was introduced in 0a72f5ee7c2a61bdb379436461269315c776b50a, which is
2.5-dev10. This fix needs to be backported to 2.5
op iterator to an explicit declaration.
No backport needed as this issue was introduced in v2.5-dev10~69 with
commit 9e5e586e35c5 ("BUG/MINOR: lua: Fix lua error handling in
`hlua_config_prepend_path()`")
---
src/hlua.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/hl
Bertrand,
On 11/24/21 10:16 PM, Bertrand Jacquin wrote:
No backport needed as this issue was introduced in v2.5-dev10~69 with
commit 9e5e586e35c5 ("BUG/MINOR: lua: Fix lua error handling in
`hlua_config_prepend_path()`")
Oh no, that's mine :-( Actually a backport is needed, b
this issue was introduced in v2.5-dev10~69 with
commit 9e5e586e35c5 ("BUG/MINOR: lua: Fix lua error handling in
`hlua_config_prepend_path()`")
---
src/hlua.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/hlua.c b/src/hlua.c
index 08735374af77..8dea91e75832 1006
On Wed, Nov 03, 2021 at 12:23:54PM +0100, Remi Tricot-Le Breton wrote:
> jwt_parse_alg would mistakenly return JWT_ALG_NONE for algorithms "",
> "n", "no" and "non" because of a strncmp misuse. It now sees them as
> unknown algorithms.
Merged, thank you Rémi!
Willy
jwt_parse_alg would mistakenly return JWT_ALG_NONE for algorithms "",
"n", "no" and "non" because of a strncmp misuse. It now sees them as
unknown algorithms.
No backport needed.
---
src/jwt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/jwt.c b/src/jwt.c
index
`"no"`, and `"non"` due to an incorrect check with `strncmp` that
also matches prefixes.
This bug did not affect the matching of the other known variants, because of
the special cased length check at the start of the function. Nonetheless these
variants are also affecte
Dear list!
Author: vishnu
Number of patches: 1
This is an automated relay of the Github pull request:
BUG/MEDIUM: lua: fix invalid return types in hlua_http_msg_get_body
Patch title(s):
BUG/MEDIUM: lua: fix invalid return types in hlua_http_msg_get_body
Link:
https://github.com
Le 10/11/21 à 6:51 PM, Tim Duesterhus a écrit :
Set an `lua_atpanic()` handler before calling `hlua_prepend_path()` in
`hlua_config_prepend_path()`.
This prevents the process from abort()ing when `hlua_prepend_path()` fails
for some reason.
see GitHub Issue #1409
This is a very minor issue
Set an `lua_atpanic()` handler before calling `hlua_prepend_path()` in
`hlua_config_prepend_path()`.
This prevents the process from abort()ing when `hlua_prepend_path()` fails
for some reason.
see GitHub Issue #1409
This is a very minor issue that can't happen in practice. No backport needed.
On Tue, Sep 14, 2021 at 02:00:16PM +0200, Thierry Fournier wrote:
(...)
> So, I guess this ommit is not a great bug, but the experieence learn
> when we play with longjmp, MEDIUM is the right level for a patch.
Thanks Thierry for the detailed analysis!
Willy
only if haproxy try to execute
Lua code without setting the safe environment. I hope this is not the
case. I’m confident because if some lus code were executed without the
panic handler, abort() were already observed for a long time.
So, I guess this ommit is not a great bug, but the experieence lear
Hello Willy,
On 09/12/2021 08:19 AM, Willy Tarreau wrote:
Bah, I discovered that one after merging the first series :-/ I've
applied it on top as a cleanup with your description above as the
commit message since it's really what it's about.
It is no problem. I apologize for the slight
On Sat, Sep 11, 2021 at 11:17:25PM +0200, Tim Duesterhus wrote:
> In one case before exiting leaving the function the panic handler was not
> reset.
>
> Introduced in 69c581a09271e91d306e7b9080502a36abdc415e, which is 2.5+.
> No backport required.
Good catch, applied as medium since it seems
On Sat, Sep 11, 2021 at 12:27:30AM +0200, Miroslav Zagorac wrote:
> On 09/11/2021 12:05 AM, Miroslav Zagorac wrote:
> > Hello all,
> >
> > the second patch from the last series of patches has been redesigned
> > here, the ist() function is used to set an empty string instead of
> > working
In one case before exiting leaving the function the panic handler was not
reset.
Introduced in 69c581a09271e91d306e7b9080502a36abdc415e, which is 2.5+.
No backport required.
---
src/hlua.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/hlua.c b/src/hlua.c
index 72d232491..915356c09
comment has been slightly corrected.
Sorry to bother you. :)
--
Zaga
What can change the nature of a man?
>From 969f6e001a2ec9fe96ff3d148c0e673afdd1f13b Mon Sep 17 00:00:00 2001
From: Miroslav Zagorac
Date: Thu, 9 Sep 2021 01:23:42 +0200
Subject: [PATCH 2/4] BUG/MINOR: opentracing: ena
?
>From 661e87f9b897924d786c887d19b211816443eed5 Mon Sep 17 00:00:00 2001
From: Miroslav Zagorac
Date: Thu, 9 Sep 2021 01:23:42 +0200
Subject: [PATCH 2/4] BUG/MINOR: opentracing: enable the use of http headers
without a set value
In case we transfer some data that does not have a set value
On Sat, Aug 28, 2021 at 11:57:01PM +0200, Tim Duesterhus wrote:
> Willy,
>
> please fill in the severity yourself.
Good catch, I didn't notice we still had those. Applied as minor as
I don't think anyone really noticed it (it would require different
arguments in different converters to be used
On Sun, Aug 29, 2021 at 12:58:22AM +0200, Tim Duesterhus wrote:
> The condition should first check whether `bsize` is reached, before
> dereferencing the offset. Even if this always works fine, due to the
> string being null-terminated, this certainly looks odd.
Applied as well, thank you!
Willy
The condition should first check whether `bsize` is reached, before
dereferencing the offset. Even if this always works fine, due to the
string being null-terminated, this certainly looks odd.
Found using GitHub's CodeQL scan.
This bug traces back to at least
Willy,
please fill in the severity yourself.
Best regards
Tim Düsterhus
PS: sample_conv_http_date has a pretty messed up indentation, mixing tabs
and spaces. It probably should be cleaned up.
Apply with `git am --scissors` to automatically cut the commit message.
-- >8 --
Using localtime
On Sun, Jun 13, 2021 at 01:13:52AM +0100, Bertrand Jacquin wrote:
> Prior to the change, spoa is installed under DESTDIR with name `bin`
Thanks Bertrand. I've merged it now, after realizing that I still had
access to this now external repo :-)
Willy
Hi Dirkjan,
On Fri, Jun 18, 2021 at 10:03:17PM +0200, Dirkjan Bussink wrote:
> Hi all,
>
> I was building HAProxy using scan-build to see if there were any issues and
> it called out an unused variable write. I think this was due to a bug that
> the err_code was not used in srv_pa
Hi all,
I was building HAProxy using scan-build to see if there were any issues and it
called out an unused variable write. I think this was due to a bug that the
err_code was not used in srv_parse_agent_check.
I’ve attached a patch to fix this issue.
Cheers,
Dirkjan Bussink
0001-BUG
e of us preferred to
maintain that ability for compatibility purposes, the general consensus
was rather that these are design mistakes to be avoided in the future.
> I found the issue, because HAProxy was serving me a gzip encoded response
> from the cache when I was not providing an 'accept
initially wanted to report *that* as a bug report. Then I
noticed that this was intentional and that it is the expected behavior
based on the HTTP specification.
I would not be surprised if this case is not correctly handled by the
majority of HTTP clients out there, because most (all?) servers
On Fri, Jun 18, 2021 at 03:46:26PM +0200, Remi Tricot-Le Breton wrote:
> Hello Tim,
>
> On 18/06/2021 15:26, Tim Düsterhus, WoltLab GmbH wrote:
> > Remi,
> >
> > please find a small fix for the 'Vary' support of the cache to correctly
> > handle the difference between a missing 'accept-encoding'
Hello Tim,
On 18/06/2021 15:26, Tim Düsterhus, WoltLab GmbH wrote:
Remi,
please find a small fix for the 'Vary' support of the cache to
correctly handle the difference between a missing 'accept-encoding'
and an empty 'accept-encoding'.
Best regards
Tim Düsterhus
Developer WoltLab GmbH
96784338
duester...@woltlab.com
www.woltlab.com
Managing director:
Marcel Werk
AG Potsdam HRB 26795 P
>From e33b3332a138319476d690acbf0aa20395df5598 Mon Sep 17 00:00:00 2001
From: Tim Duesterhus
Date: Fri, 18 Jun 2021 15:09:28 +0200
Subject: [PATCH] BUG/MINOR: cache: Correctly handle existing-but-em
Prior to the change, spoa is installed under DESTDIR with name `bin`
---
Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/Makefile b/Makefile
index 5de6135ec7d6..52eb43e5f938 100644
--- a/Makefile
+++ b/Makefile
@@ -68,6 +68,7 @@ spoa: $(OBJS)
$(LD) $(LDFLAGS) -o $@ $^
who provide packages.
> >
> > I'll retag your patch as BUG/MEDIUM as it really addresses an initialization
> > issue and the fix is not that trivial. We may add the above info to the
> > commit message if needed.
> >
>
> Hello Willy,
>
> I adde
On 06/10/2021 04:20 AM, Willy Tarreau wrote:
Thank you Miroslav. Just to be sure, is this in anyway related to the
fix or not ? We need to make sure that we maintain a smooth upgrade
path for those who provide packages.
I'll retag your patch as BUG/MEDIUM as it really addresses
is in anyway related to the
fix or not ? We need to make sure that we maintain a smooth upgrade
path for those who provide packages.
I'll retag your patch as BUG/MEDIUM as it really addresses an initialization
issue and the fix is not that trivial. We may add the above info to the
commit message if needed.
Willy
I forgot to mention that one should take the latest version of the
opentracing c wrapper (it is now 1.1.0).
https://github.com/haproxytech/opentracing-c-wrapper
--
Zaga
What can change the nature of a man?
rom fd06ebf4cab6dcef649e1ca5a6f38db33ae68b26 Mon Sep 17 00:00:00 2001
From: Miroslav Zagorac
Date: Thu, 10 Jun 2021 01:19:13 +0200
Subject: [PATCH 1/2] Revert "BUG/MINOR: opentracing: initialization after
establishing daemon mode"
This reverts commit f2263435d71964d1aa3eb80df64
On 06/09/2021 09:10 AM, Willy Tarreau wrote:
Hi Miroslav,
On Mon, Jun 07, 2021 at 04:55:21PM +0200, Miroslav Zagorac wrote:
...
In fact, the only access to these files is achieved only once at the
beginning of the HAProxy process, in the initialization of threads.
After this initialization, no
Hi Miroslav,
On Mon, Jun 07, 2021 at 04:55:21PM +0200, Miroslav Zagorac wrote:
> From 4bbbe5fd3e66a37ec9703723ba22b742e7926a07 Mon Sep 17 00:00:00 2001
> From: Miroslav Zagorac
> Date: Mon, 7 Jun 2021 16:21:31 +0200
> Subject: [PATCH] BUG/MINOR: opentracing: fixed files existence che
16:21:31 +0200
Subject: [PATCH] BUG/MINOR: opentracing: fixed files existence check in chroot
mode
If the 'chroot' keyword is used in the HAProxy configuration file,
HAProxy reports an error when initializing the OpenTracing API
library.
The problem is that HAProxy also executes chdir("/&
Zagorac
Date: Mon, 7 Jun 2021 16:21:31 +0200
Subject: [PATCH] BUG/MINOR: opentracing: fixed files existence check in chroot
mode
If the 'chroot' keyword is used in the HAProxy configuration file,
HAProxy reports an error when initializing the OpenTracing API
library.
The problem is that HAProxy
Hi Tim,
On Mon, May 10, 2021 at 11:21:20PM +0200, Tim Duesterhus wrote:
> These places were forgotten when the normalizers were renamed.
(...)
All of your 3 patches applied, thank you!
Willy
These places were forgotten when the normalizers were renamed.
Bug introduced in 5be6ab269e5606aef954f39d6717b024f97b3789, which is 2.4. No
backport needed.
---
src/http_act.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/http_act.c b/src/http_act.c
index b8413f331
Currently the delimiter is hardcoded as ampersand (&) but the function takes
the delimiter as a paramter.
This patch replaces the hardcoded ampersand with the given delimiter.
---
src/uri_normalizer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/uri_normalizer.c
Hi Thayne,
On Sun, Apr 11, 2021 at 11:26:59PM -0600, Thayne McCombs wrote:
> Adjust the size of the sample buffer before we change the "area"
> pointer. The change in size is calculated as the difference between the
> original pointer and the new start pointer. But since the
>
Adjust the size of the sample buffer before we change the "area"
pointer. The change in size is calculated as the difference between the
original pointer and the new start pointer. But since the
`smp->data.u.str.area` assignment results in `smp->data.u.str.area` and
`start` being the same pointer,
"Robin H. Johnson" wrote:
> Hi,
> Wondering if you could make a new 1.8.x release to get the fix for the
> freq counter bug into more systems?
> dde80e111 BUG/MEDIUM: time: make sure to always initialize the global tick
> 491b86ed0 BUG/MEDIUM: freq_ctr/threads: use t
Hi,
Wondering if you could make a new 1.8.x release to get the fix for the
freq counter bug into more systems?
dde80e111 BUG/MEDIUM: time: make sure to always initialize the global tick
491b86ed0 BUG/MEDIUM: freq_ctr/threads: use the global_now_ms variable
It's a problem for anybody using
Hi,
Wondering if you could make a new 1.8.x release to get the fix for the
freq counter bug into more systems?
dde80e111 BUG/MEDIUM: time: make sure to always initialize the global tick
491b86ed0 BUG/MEDIUM: freq_ctr/threads: use the global_now_ms variable
It's a problem for anybody using
Le 02/04/2021 à 22:12, Thayne McCombs a écrit :
Commit c20ad0d8dbd1bb5707bbfe23632415c3062e046c (BUG/MINOR: tools: make
parse_time_err() more strict on the timer validity) broke parsing the "us"
unit in timers. It caused `parse_time_err()` to return the string "s",
whic
Oh, and this should be backported to all supported versions.
Commit c20ad0d8dbd1bb5707bbfe23632415c3062e046c (BUG/MINOR: tools: make
parse_time_err() more strict on the timer validity) broke parsing the "us"
unit in timers. It caused `parse_time_err()` to return the string "s",
which indicates an error.
Now if the "u" is
Hi Miroslav,
On Fri, Apr 02, 2021 at 01:44:31PM +0200, Miroslav Zagorac wrote:
> Hello,
>
> This patch solves the problem reported in github issue #1204, where the
> OpenTracing filter cannot communicate with the selected tracer if HAProxy is
> run in daemon mode.
>
> This patch should be
change the nature of a man?
>From fe482c8adaa703e790b4d1995255b9754799b149 Mon Sep 17 00:00:00 2001
From: Miroslav Zagorac
Date: Fri, 2 Apr 2021 04:25:47 +0200
Subject: [PATCH] BUG/MINOR: opentracing: initialization after establishing
daemon mode
This patch solves the problem reported in git
On Wed, Mar 10, 2021 at 08:24:24AM +0100, Baptiste wrote:
> On Wed, Mar 10, 2021 at 5:15 AM Daniel Corbett wrote:
>
> > Hello,
> >
> >
> >
> >
> >
> > The recently introduced Financial Information eXchange (FIX)
> >
> > converters have some hard coded tags based on the specification that
> >
> >
On Wed, Mar 10, 2021 at 5:15 AM Daniel Corbett wrote:
> Hello,
>
>
>
>
>
> The recently introduced Financial Information eXchange (FIX)
>
> converters have some hard coded tags based on the specification that
>
> were misspelled. Specifically, SenderComID and TargetComID should
>
> be
].
This patch updates all references, which includes the converters
themselves, the regression test, and the documentation.
[1] https://fiximate.fixtrading.org/en/FIX.5.0SP2_EP264/tag49.html
[2] https://fiximate.fixtrading.org/en/FIX.5.0SP2_EP264/tag56.html
Thanks,
-- Daniel
0001-BUG
Hi Tim,
Ah, good eye! It does appear to be the same, but in my case it's due to short
TTLs vs large responses.
Thanks. I'll link this over there.
Best,
Luke
—
Luke Seelenbinder
Stadia Maps | Founder
stadiamaps.com | (864) 735-8533
> On 6 Mar 2021, at 19:03, Tim Düsterhus wrote:
>
> Luke,
>
Luke,
Am 06.03.21 um 18:57 schrieb Luke Seelenbinder:
> I just upgraded one of our HAProxy installations to 2.2.10 (on Debian using
> the from the HAProxy maintained apt repo). It appears the changes made to how
> SRV records are expired is causing issues, at least with short-lived TTLs in
>
Hi List,
I just upgraded one of our HAProxy installations to 2.2.10 (on Debian using the
from the HAProxy maintained apt repo). It appears the changes made to how SRV
records are expired is causing issues, at least with short-lived TTLs in the
SRV records.
The issue I'm seeing is the record
loop (data=data@entry=0x0) at
src/haproxy.c:3035
#9 0x55596c90 in main (argc=, argv=0x7fffe818)
at src/haproxy.c:3723
quit)
this bug was introduced by commit
e3f7bd5ae9e969cbfe87e4130d06bff7a3e814c6 ("MEDIUM:
contrib/prometheus-exporter: add listen stats"), which is
596c90 in main (argc=, argv=0x7fffe818) at
src/haproxy.c:3723
quit)
this bug was introduced by commit
e3f7bd5ae9e969cbfe87e4130d06bff7a3e814c6 ("MEDIUM:
contrib/prometheus-exporter: add listen stats"), which is present for
2.4 only, so no backport needed.
Signed-of
Hello Christopher,
On Mon, Feb 8, 2021 at 11:53 PM William Dauchy wrote:
> Since commit 3169471964fdc49963e63f68c1fd88686821a0c4 ("MINOR: Add
> server port field to server state file.") max_fields was not increased
> on version number 1. So this patch aims to fix it. This should be
> backported
Since commit 3169471964fdc49963e63f68c1fd88686821a0c4 ("MINOR: Add
server port field to server state file.") max_fields was not increased
on version number 1. So this patch aims to fix it. This should be
backported as far as v1.8, but the numbering should be adpated depending
on the version:
Since commit 3169471964fdc49963e63f68c1fd88686821a0c4 ("MINOR: Add
server port field to server state file.") max_fields was not increased
on version number 1. So this patch aims to fix it. This should be
backported as far as v1.8, but the numbering should be adpated depending
on the version:
o a change of behavior along the years. So this patch can potentially
be backported up to v1.8 but we must be careful while doing so, as the
code has changed a lot. That being said, the bug being not very
impacting I would be fine keeping it for 2.4 only.
Signed-off-by: William Dauchy
---
src/ser
small consistency problem with `addr` and `agent-addr` options:
for the both options, the last one parsed is always used to set the
agent-check addr. Thus these two lines don't have the same behavior:
server ... addr agent-addr
server ... agent-addr addr
After this patch `agent-addr`
small consistency problem with `addr` and `agent-addr` options:
for the both options, the last one parsed is always used to set the
agent-check addr. Thus these two lines don't have the same behavior:
server ... addr agent-addr
server ... agent-addr addr
I was not really able to
o a change of behavior along the years. So this patch can potentially
be backported up to v1.8 but we must be careful while doing so, as the
code has changed a lot. That being said, the bug being not very
impacting I would be fine keeping it for 2.4 only.
Signed-off-by: William Dauchy
---
src/ser
Hi Christopher,
Thanks for the review.
On Tue, Feb 2, 2021 at 10:21 AM Christopher Faulet wrote:
> So, it may be good to take a global look at this stuff. I may missed
> something.
> And be carefull for the backports because the health-checks were refactored in
> the 2.2.
ok I will come back
Le 31/01/2021 à 11:11, William Dauchy a écrit :
while reading `update_server_addr_port` I found out some things which
can be seen as incoherency. I hope I did not overlooked anything:
- one comment is stating check's address should be updated if it uses
the server one; however the condition
while reading `update_server_addr_port` I found out some things which
can be seen as incoherency. I hope I did not overlooked anything:
- one comment is stating check's address should be updated if it uses
the server one; however the condition checks if `SRV_F_CHECKADDR` is
set; this flag is
when we set check port flag, we need to set a flag on server.
this is missing since the origin of the feature: commit
5094656a67fa1b56f30cd2316adb675ca9d2a79a ("MINOR: cli: change a server
health check port through the stats socket"). So it can potentially be
backport up to v1.8.
Signed-off-by:
101 - 200 of 2099 matches
Mail list logo
