bartbutler
Repos
16
Followers
37

Events

Fix deprecation issues for PHP 8.1

Merge pull request #4 from BafS/fix-php81-1

Fix deprecation issues for PHP 8.1

Created at 4 hours ago
pull request closed
Fix deprecation issues for PHP 8.1

Taken from https://github.com/ezyang/htmlpurifier/pull/310

Created at 4 hours ago
issue comment
Add `timeout retry` setting to disconnect from `timeout connect`

Not at all, sounds good. Thanks!

Created at 1 week ago
issue comment
Add `timeout retry` setting to disconnect from `timeout connect`

Took a little time to figure out our haproxy build setup, but I can confirm that this patch solves our problem entirely as far as I can tell. Any chance we could get it backported to the 2.4 LTS or should we apply the patch ourselves in our build process?

Created at 1 week ago
issue comment
Add `timeout retry` setting to disconnect from `timeout connect`

Thank you for looking into it! We very much appreciate it.

Created at 1 week ago
issue comment
Add `timeout retry` setting to disconnect from `timeout connect`

Hmmm, I think we tend to use balance source to try to impose a soft stickiness on connections to our service because we feel it's better to be down 100% for 5% of users than have 5% of requests fail for all users.

In our experience, redispatch using balance source still always go to other servers. Would it be possible to have the no-delay apply for any redispatch?

Created at 1 week ago
issue comment
Add `timeout retry` setting to disconnect from `timeout connect`

It's certainly possible we have something strange going on, but our setup is as follows:

option redispatch 1 retries 3 timeout connect 3500

in server defaults. We enforce the connection limit to the backend servers with a firewall reject rule, so with curl or similar you get an instant "connection refused".

When we do this, we always have a 1s wait before redispatch, always, despite the reject from the first server should be much faster.

I suppose you could reproduce this with a dummy health check that always returns success, blocking all connections to a backend with the firewall, and watch the request duration of the redispatched requests.

The other possibility is that the connection refused is not being registered correctly and it's treating it as a connection timeout, but if that was the case it would be 3.5s not 1s I would think.

Created at 1 week ago
issue comment
Add `timeout retry` setting to disconnect from `timeout connect`

Understood. We have configured our backend servers to reject connections when they are "full". This is basically instantaneous rather than a timeout. Health checks are on a different port so they aren't rejected and the server stays up in HAproxy in this particular case.

We've configured redispatches to immediately try a different backend rather than retrying the original server. However, we noticed that even when the retry is going to a different server entirely, the min(timeout connect, 1s) is enforced, and we'd like to eliminate it.

So another way to address this could be to not enforce the min(timeout connect, 1s) at all for redispatches to other servers as opposed to retries to the same server, unless you see a reason that someone might want to configure a wait for redispatches too, in which case I guess a configurable retry timeout would be more flexible.

Created at 1 week ago
opened issue
Add `timeout retry` settings to disconnect from `timeout connect`

Your Feature Request

Rather than reusing timeout connect and clamping to 1s as is done today for retries, we would like to request that an explicit separate timeout retry setting be added so that we can control these two behaviors independently.

What are you trying to do?

As discussed in https://github.com/haproxy/haproxy/issues/1867, we were trying to lower the time HAproxy waited to retry requests, and eventually found that the way to do this was to lower timeout connect. We did this, but it had unintended negative consequences when HAproxy was under load and we had to revert.

We'd like to keep timeout connect higher to mitigate these issues but lower the wait for retries (which we redispatch immediately) when a given backend server is alive and well but at capacity (our current architecture does not allow us to use maxconn effectively for this).

Output of haproxy -vv

HAProxy version 2.4.15-7782e23 2022/03/14 - https://haproxy.org/
Status: long-term supported branch - will stop receiving fixes around Q2 2026.
Known bugs: http://www.haproxy.org/bugs/bugs-2.4.15.html
Running on: Linux 5.18.3-1.el8.elrepo.x86_64 #1 SMP PREEMPT_DYNAMIC Wed Jun 8 10:40:51 EDT 2022 x86_64
Build options :
  TARGET  = linux-glibc
  CPU     = generic
  CC      = cc
  CFLAGS  = -O2 -g -Wall -Wextra -Wdeclaration-after-statement -fwrapv -Wno-unused-label -Wno-sign-compare -Wno-unused-parameter -Wno-clobbered -Wno-missing-field-initializers -Wtype-limits
  OPTIONS = USE_PCRE=1 USE_PTHREAD_PSHARED=1 USE_OPENSSL=1 USE_LUA=1 USE_ZLIB=1 USE_TFO=1 USE_SYSTEMD=1 USE_OT=1 USE_PROMEX=1
  DEBUG   = 

Feature list : +EPOLL -KQUEUE +NETFILTER +PCRE -PCRE_JIT -PCRE2 -PCRE2_JIT +POLL -PRIVATE_CACHE +THREAD +PTHREAD_PSHARED +BACKTRACE -STATIC_PCRE -STATIC_PCRE2 +TPROXY +LINUX_TPROXY +LINUX_SPLICE +LIBCRYPT +CRYPT_H +GETADDRINFO +OPENSSL +LUA +FUTEX +ACCEPT4 -CLOSEFROM +ZLIB -SLZ +CPU_AFFINITY +TFO +NS +DL +RT -DEVICEATLAS -51DEGREES -WURFL +SYSTEMD -OBSOLETE_LINKER +PRCTL -PROCCTL +THREAD_DUMP -EVPORTS +OT -QUIC +PROMEX -MEMORY_PROFILING

Default settings :
  bufsize = 16384, maxrewrite = 1024, maxpollevents = 200

Built with multi-threading support (MAX_THREADS=64, default=64).
Built with OpenSSL version : OpenSSL 1.1.1n  15 Mar 2022
Running on OpenSSL version : OpenSSL 1.1.1n  15 Mar 2022
OpenSSL library supports TLS extensions : yes
OpenSSL library supports SNI : yes
OpenSSL library supports : TLSv1.0 TLSv1.1 TLSv1.2 TLSv1.3
Built with Lua version : Lua 5.4.4
Built with the Prometheus exporter as a service
Built with network namespace support.
Built with OpenTracing support.
Built with zlib version : 1.2.7
Running on zlib version : 1.2.11
Compression algorithms supported : identity("identity"), deflate("deflate"), raw-deflate("deflate"), gzip("gzip")
Built with transparent proxy support using: IP_TRANSPARENT IPV6_TRANSPARENT IP_FREEBIND
Built with PCRE version : 8.32 2012-11-30
Running on PCRE version : 8.42 2018-03-20
PCRE library supports JIT : no (USE_PCRE_JIT not set)
Encrypted password support via crypt(3): yes
Built with gcc compiler version 4.8.5 20150623 (Red Hat 4.8.5-44)

Available polling systems :
      epoll : pref=300,  test result OK
       poll : pref=200,  test result OK
     select : pref=150,  test result OK
Total: 3 (3 usable), will use epoll.

Available multiplexer protocols :
(protocols marked as <default> cannot be specified using 'proto' keyword)
              h2 : mode=HTTP       side=FE|BE     mux=H2       flags=HTX|CLEAN_ABRT|HOL_RISK|NO_UPG
            fcgi : mode=HTTP       side=BE        mux=FCGI     flags=HTX|HOL_RISK|NO_UPG
       <default> : mode=HTTP       side=FE|BE     mux=H1       flags=HTX
              h1 : mode=HTTP       side=FE|BE     mux=H1       flags=HTX|NO_UPG
       <default> : mode=TCP        side=FE|BE     mux=PASS     flags=
            none : mode=TCP        side=FE|BE     mux=PASS     flags=NO_UPG

Available services : prometheus-exporter
Available filters :
	[  OT] opentracing
	[SPOE] spoe
	[CACHE] cache
	[FCGI] fcgi-app
	[COMP] compression
	[TRACE] trace
Created at 1 week ago
closed issue
Modify redispatch minimum timeout?

Hello,

We're trying to use firewall rules( iptables) to work around an issue with our Apache-based backends. What we would like to do is be able to limit connections to a given backend with iptables and have HAproxy redispatch the request immediately to another server. We've tested this and it works fine except that HAproxy waits the full connect timeout before redispatching (in our case 1s) rather than recognizing that the connection was rejected immediately. Any ideas how we can make this faster? We've tried with and without tfo and with various --reject-with iptables rules but the behavior is the same.

Thanks in advance!

Created at 2 weeks ago
issue comment
Backend TCP connect waits for full timeout even when connection refused

I think it's the redispatch which is doing it:

"In order to avoid immediate reconnections to a server which is restarting, a turn-around timer of min("timeout connect", one second) is applied before a retry occurs."

Could we get a way to lower this? In our case we are redispatching immediately to a different server so the server restarting use case is not relevant.

Created at 2 weeks ago
opened issue
Backend TCP connect waits for full timeout even when connection refused

Hello,

We're trying to use firewall rules( iptables) to work around an issue with our Apache-based backends. What we would like to do is be able to limit connections to a given backend with iptables and have HAproxy redispatch the request immediately to another server. We've tested this and it works fine except that HAproxy waits the full connect timeout before redispatching (in our case 1s) rather than recognizing that the connection was rejected immediately. Any ideas how we can make this faster? We've tried with and without tfo and with various --reject-with iptables rules but the behavior is the same.

Thanks in advance!

Created at 2 weeks ago
issue comment
Incorrect unread emails counters rendered in the Proton UI

So a looked at the code and found this comment:

FIXME: Deprecated, should use the MessageCounts and ConversationCounts queries explicitly

Basically, counts are included for the WebMail appversion header automatically for legacy reasons but not for others because it's inefficient.

Web mail should fix this by requesting the counts explicitly. I will ask them to do this. In the mean time, if you want the message or conversation counts or both you just need to include MessageCounts and/or ConversationCounts query parameters (values are not important) and they'll be put in the response.

Created at 2 months ago