Re: [PATCH] MEDIUM/RFC: Implement time-based server latency metrics

Hi Krishna, On Thu, Jan 05, 2017 at 11:15:46AM +0530, Krishna Kumar (Engineering) wrote: > Hi Willy, > > If required, I can try to make the "hard-coded periods" changes too, but > want > to hear your opinion as the code gets very complicated, and IMHO, may not > give correct results depending on

ALERT:sendmsg logger #1 failed: Resource temporarily unavailable (errno=11)

Hi all, On one of my haproxy's I get the following message on reload: [ALERT] 004/070949 (21440) : sendmsg logger #1 failed: Resource temporarily unavailable (errno=11) Has anyone seen this before or any pointers where to look for to correct this? Thanks, Igor

Re: 400 error on cookie string

  Yes, please apply Willy's patch to the 1.7.1 release and tell us what happens. Everything looks good. No errors.   About 1.6.11. It was in the first days of December. May be I've mixed up something.I can test again tomorrow if you want  It was 1.6.10. I think I've made some mistakes in paths so m

Re: [PATCH] MEDIUM/RFC: Implement time-based server latency metrics

Hi Willy, If required, I can try to make the "hard-coded periods" changes too, but want to hear your opinion as the code gets very complicated, and IMHO, may not give correct results depending on when the request is made. All the other changes are doable. Hoping to hear from you on this topic, pl

Re: TLS-PSK support for haproxy?

I have a working patch for this, but it's very ugly currently (minimal error checking, no warnings/messages, no docs, very basic tests done only, etc.) I expect to have a version for review by EOW (depending on the workload, maybe a bit sooner). Regards, Nenad On 1/2/2017 10:11 AM, Gil Bahat wro

Re: 400 error on cookie string

Hi Willy, Am 03.01.2017 um 21:10 schrieb Willy Tarreau: It was not dropped since the server SACKed it (but until it's within the window the stack is free to change its mind). In fact following a TCP stream in wireshark never gives any useful information. You *always* need the absolute sequence

Re: HAProxy's health checks and maxconn limits

Hi Jiri, Am 04.01.2017 um 11:38 schrieb Jiri Mencak: Hi, we are using HAProxy with its default 2000 maxconn limit and a listen block: listen stats :1936 mode http monitor-uri /healthz which we use to check HAProxy's "health" by external HTTP probes. The behaviour I'm seeing is tha

Re: (Без темы)

About 1.6.11. It was in the first days of December. May be I've mixed up something. I can test again tomorrow if you want 04.01.2017, 17:43, "c...@xmonetize.net" : Hi, Thank you very much for fix. I just want to mention that I had this issue in 1.6.11 too.My name is Aleksey Gordeev. I'm glad that m

[no subject]

 Hi, Thank you very much for fix. I just want to mention that I had this issue in 1.6.11 too.My name is Aleksey Gordeev. I'm glad that my information was useful. Also I will wait any commit, branch or tag to test it. It is very easy to test it.  I found it and fixed it! It was me again who added a

SOLVED! (Was: 400 error on cookie string)

I found it and fixed it! It was me again who added a bug in 1.7 with the optimizations for large headers and large requests. If certain conditions are met, we could read the \r from previous data (as we guessed) and complain that the next byte was not an LF once the remaining part arrived. I'm in

Re: 400 error on cookie string

Hi guys, On Tue, Jan 03, 2017 at 09:10:21PM +0100, Willy Tarreau wrote: > However when looking at the error capture, the request is correct. But as > you can see, it's reported as wrong from offset 1453, hence one byte past > the end of the first segment. Thus I suspect that we have something wron

HAProxy's health checks and maxconn limits

Hi, we are using HAProxy with its default 2000 maxconn limit and a listen block: listen stats :1936 mode http monitor-uri /healthz which we use to check HAProxy's "health" by external HTTP probes. The behaviour I'm seeing is that once the default 2000 maxconn limit is reached, HAProxy s

[PATCH 1/2] MEDIUM: stats: Add JSON output option to show (info|stat)

Add a json parameter to show (info|stat) which will output information in JSON format. A follow-up patch will add a JSON schema which describes the format of the JSON output of these commands. The JSON output is without any extra whitespace in order to reduce the volume of output. For human consum

[PATCH 0/2] MEDIUM: stats: Add JSON output option to show (info|stat)

Hi, this short series is an RFC implementation of adding JSON format output to show (info|stat). It also adds a new show schema json stats command to allow retreival of the schema which describes the JSON output of show (info|stat). Some areas for possible discussion: * Use of STAT_STARTED in fir

[PATCH 2/2] MEDIUM: stats: Add show json schema

This may be used to output the JSON schema which describes the output of show info json and show stats json. The JSON output is without any extra whitespace in order to reduce the volume of output. For human consumption passing the output through a pretty printer may be helpful. e.g.: $ echo "sho