stable-bot: WARNING: 87 bug fixes in queue for next release - 1.9
Hi, This is a friendly bot that watches fixes pending for the next haproxy-stable release! One such e-mail is sent periodically once patches are waiting in the last maintenance branch, and an ideal release date is computed based on the severity of these fixes and their merge date. Responses to this mail must be sent to the mailing list. Last release 1.9.8 was issued on 2019/05/13. There are currently 87 patches in the queue cut down this way: - 3 MAJOR, first one merged on 2019/05/27 - 46 MEDIUM, first one merged on 2019/05/21 - 38 MINOR, first one merged on 2019/05/16 Thus the computed ideal release date for 1.9.9 would be 2019/06/10, which was six weeks ago. The current list of patches in the queue is: - MAJOR : listener: fix thread safety in resume_listener() - MAJOR : mux-h1: Don't crush trash chunk area when outgoing message is formatted - MAJOR : lb/threads: make sure the avoided server is not full on second pass - MEDIUM : sessions: Don't keep an extra idle connection in sessions. - MEDIUM : spoe: Don't use the SPOE applet after releasing it - MEDIUM : connections: Don't try to send early data if we have no mux. - MEDIUM : WURFL: segfault in wurfl-get() with missing info. - MEDIUM : threads: Fix build for 32bits arch with dwcas. - MEDIUM : lb_fas: Don't test the server's lb_tree from outside the lock - MEDIUM : compression: Set Vary: Accept-Encoding for compressed responses - MEDIUM : connections: Always call shutdown, with no linger. - MEDIUM : compression/htx: Fix the adding of the last data block - MEDIUM : mux-h2: Remove the padding length when a DATA frame size is checked - MEDIUM : connections: Don't call shutdown() if we want to disable linger. - MEDIUM : streams: Don't switch from SI_ST_CON to SI_ST_DIS on read0. - MEDIUM : ssl: Don't attempt to set alpn if we're not using SSL. - MEDIUM : mux-h1: Always release H1C if a shutdown for writes was reported - MEDIUM : mux-h1: Don't switch the mux in BUSY mode on 1xx messages - MEDIUM : fd/threads: fix excessive CPU usage on multi-thread accept - MEDIUM : dns: make the port numbers unsigned - MEDIUM : mux-h1: Don't skip the TCP splicing when there is no more data to read - MEDIUM : h2: Don't forget to set h2s->cs to NULL after having free'd cs. - MEDIUM : http: fix "http-request reject" when not final - MEDIUM : checks: Don't attempt to receive data if we already subscribed. - MEDIUM : da: cast the chunk to string. - MEDIUM : lb_fwlc: Don't test the server's lb_tree from outside the lock - MEDIUM : connections: Don't use ALPN to pick mux when in mode TCP. - MEDIUM : mux-h2: make sure the connection timeout is always set - MEDIUM : mux-h1: only check input data for the current stream, not next one - MEDIUM : mworker: don't call the thread and fdtab deinit - MEDIUM : vars: make sure the scope is always valid when accessing vars - MEDIUM : proto-htx: Not forward too much data when 1xx reponses are handled - MEDIUM : h2/htx: Update data length of the HTX when the cookie list is built - MEDIUM : threads: fix double-word CAS on non-optimized 32-bit platforms - MEDIUM : http/htx: unbreak option http_proxy - MEDIUM : checks: Make sure the tasklet won't run if the connection is closed. - MEDIUM : mux-h1: Use buf_room_for_htx_data() to detect too large messages - MEDIUM : mux-h2: Reset padlen when several frames are demux - MEDIUM : queue: fix the tree walk in pendconn_redistribute. - MEDIUM : mux-h1: Trim excess server data at the end of a transaction - MEDIUM : stream-int: Don't rely on CF_WRITE_PARTIAL to unblock opposite si - MEDIUM : connection: Use the session to get the origin address if needed. - MEDIUM : checks: Don't attempt to read if we destroyed the connection. - MEDIUM : mux-h1: Don't release h1 connection if there is still data to send - MEDIUM : proto_htx: Introduce the state ENDING during forwarding - MEDIUM : connection: fix multiple handshake polling issues - MEDIUM : vars: make the tcp/http unset-var() action support conditions - MEDIUM : servers: Don't forget to set srv_cs to NULL if we can't reuse it. - MEDIUM : tcp-check: unbreak multiple connect rules again - MINOR : http_fetch: Fix http_auth/http_auth_group when called from TCP rules - MINOR : mux-h1: Report EOI instead EOS on parsing error or H2 upgrade - MINOR : ssl_sock: Fix memory leak when disabling compression - MINOR : htx: Remove a forgotten while loop in htx_defrag() - MINOR : fl_trace/htx: Be sure to always forward trailers and EOM - MINOR : mux-h1: Wake up the mux if it is busy when a 1xx response is handled - MINOR : backend: do not try to install a mux when the connection failed - MINOR : http-rules: mention "deny_status" for "deny" in the
stable-bot: WARNING: 25 bug fixes in queue for next release - 1.8
Hi, This is a friendly bot that watches fixes pending for the next haproxy-stable release! One such e-mail is sent periodically once patches are waiting in the last maintenance branch, and an ideal release date is computed based on the severity of these fixes and their merge date. Responses to this mail must be sent to the mailing list. Last release 1.8.20 was issued on 2019/04/25. There are currently 25 patches in the queue cut down this way: - 3 MAJOR, first one merged on 2019/04/30 - 17 MEDIUM, first one merged on 2019/04/29 - 5 MINOR, first one merged on 2019/04/29 Thus the computed ideal release date for 1.8.21 would be 2019/05/14, which was nine weeks ago. The current list of patches in the queue is: - MAJOR : map/acl: real fix segfault during show map/acl on CLI - MAJOR : listener: fix thread safety in resume_listener() - MAJOR : lb/threads: make sure the avoided server is not full on second pass - MEDIUM : connection: fix multiple handshake polling issues - MEDIUM : contrib/modsecurity: If host header is NULL, don't try to strdup it - MEDIUM : mux-h2: make sure the connection timeout is always set - MEDIUM : dns: make the port numbers unsigned - MEDIUM : listener: Fix how unlimited number of consecutive accepts is handled - MEDIUM : http: fix "http-request reject" when not final - MEDIUM : vars: make the tcp/http unset-var() action support conditions - MEDIUM : da: cast the chunk to string. - MEDIUM : vars: make sure the scope is always valid when accessing vars - MEDIUM : port_range: Make the ring buffer lock-free. - MEDIUM : compression: Set Vary: Accept-Encoding for compressed responses - MEDIUM : spoe: arg len encoded in previous frag frame but len changed - MEDIUM : lb_fas: Don't test the server's lb_tree from outside the lock - MEDIUM : lb_fwlc: Don't test the server's lb_tree from outside the lock - MEDIUM : http/htx: unbreak option http_proxy - MEDIUM : tcp-check: unbreak multiple connect rules again - MEDIUM : spoe: Don't use the SPOE applet after releasing it - MINOR : deinit/threads: make hard-stop-after perform a clean exit - MINOR : ssl_sock: Fix memory leak when disabling compression - MINOR : http_fetch: Rely on the smp direction for "cookie()" and "hdr()" - MINOR : http: Call stream_inc_be_http_req_ctr() only one time per request - MINOR : http-rules: mention "deny_status" for "deny" in the error message --- The haproxy stable-bot is freely provided by HAProxy Technologies to help improve the quality of each HAProxy release. If you have any issue with these emails or if you want to suggest some improvements, please post them on the list so that the solutions suiting the most users can be found.
stable-bot: INFO: 14 bug fixes in queue for next release - 2.0
Hi, This is a friendly bot that watches fixes pending for the next haproxy-stable release! One such e-mail is sent periodically once patches are waiting in the last maintenance branch, and an ideal release date is computed based on the severity of these fixes and their merge date. Responses to this mail must be sent to the mailing list. Last release 2.0.2 was issued on 2019/07/16. There are currently 14 patches in the queue cut down this way: - 3 MEDIUM, first one merged on 2019/07/19 - 11 MINOR, first one merged on 2019/07/19 Thus the computed ideal release date for 2.0.3 would be 2019/08/16, which is in four weeks or less. The current list of patches in the queue is: - MEDIUM : http/htx: unbreak option http_proxy - MEDIUM : checks: Don't attempt to receive data if we already subscribed. - MEDIUM : mux-h1: Trim excess server data at the end of a transaction - MINOR : checks: do not exit tcp-checks from the middle of the loop - MINOR : session: Emit an HTTP error if accept fails only for H1 connection - MINOR : cache/htx: Make maxage calculation HTX aware - MINOR : http_htx: Initialize HTX error messages for TCP proxies - MINOR : debug: Remove flags CO_FL_SOCK_WR_ENA/CO_FL_SOCK_RD_ENA - MINOR : http_fetch: Fix http_auth/http_auth_group when called from TCP rules - MINOR : mux-h1: Close server connection if input data remains in h1_detach() - MINOR : session: Send a default HTTP error if accept fails for a H1 socket - MINOR : hlua: Make the function txn:done() HTX aware - MINOR : backend: do not try to install a mux when the connection failed - MINOR : dns: remove irrelevant dependency on a client connection --- The haproxy stable-bot is freely provided by HAProxy Technologies to help improve the quality of each HAProxy release. If you have any issue with these emails or if you want to suggest some improvements, please post them on the list so that the solutions suiting the most users can be found.
Re: Random 502's and instant 504's after upgrading
On 2019-07-19 14:05, Christopher Faulet wrote: Le 19/07/2019 à 09:36, Sander Klein a écrit : --- HTTP/1.1 200 OK Server: nginx Date: Fri, 19 Jul 2019 07:32:03 GMT Content-Type: application/json; charset=UTF-8 Transfer-Encoding: chunked Vary: Accept-Encoding Vary: Accept-Encoding Cache-Control: private, must-revalidate ETag: "178c3f242b0151fe57e02f6e8817ce3a" Access-Control-Allow-Origin: * Access-Control-Allow-Methods: POST, GET, OPTIONS, PUT, PATCH, DELETE, HEAD Length: unspecified [application/json] --- Maybe the 'Length: unspecified' has something to do with it. No, this line is reported by wget because there is no "Content-Length" header. Heh, doh, sorry about that :-) So, as I said, I pushed a fix (https://github.com/haproxy/haproxy/commit/03627245). It was backported to 2.0. Could you check if it fixes your issue about 502 errors ? I just pathed up 2.0.2 and tested it. I still get 502's but a lot less. I'm not sure if this is because I do less request/s or I hit something else. The show errors show: --- [20/Jul/2019:19:34:45.629] backend cluster1-xx (#11): invalid response frontend cluster1 (#3), server xxx (#1), event #0, src x.x.x.x:52007 buffer starts at 0 (including 0 out), 10809 free, len 5575, wraps at 16336, error at position 0 H1 connection flags 0x, H1 stream flags 0x4094 H1 msg state MSG_RPVER(10), H1 msg flags 0x1404 H1 chunk len 0 bytes, H1 body len 0 bytes : --- --- [20/Jul/2019:19:40:32.643] backend cluster1-xx (#11): invalid response frontend webservices (#18), server xxx (#2), event #13, src x:x:x:x:x:x:x:x:59724 buffer starts at 0 (including 0 out), 16377 free, len 7, wraps at 16384, error at position 0 H1 connection flags 0x, H1 stream flags 0x4094 H1 msg state MSG_RPBEFORE(8), H1 msg flags 0x1404 H1 chunk len 0 bytes, H1 body len 0 bytes : 0 :10}]}} --- There is of course more with the first one, but I do not want to put that on the mailinglist. It seems like a partial response body. I can send it to you private if you want. For 504 errors, I have no idea for now. I'm not sure about these 504's either. I had a couple of reports about these and 1 of our developers had it one time, but I haven't seen it myself or seen any proof about this. But like I said, the logs show nothing. I will keep my eye on this. Sander 0x2E78FBE8.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
