This patch does appear to have solved the issue reported, but it
introduced another.
If I use `http-request add-header` with %rt in the value to add the
request ID, and then I also use it in `unique-id-format`, the 2 settings
get different values. the value used for`http-request add-header` will
Actually I sent that prematurely. The behavior is actually even simpler.
With `http-request add-header`, %rt is one less than when used in a
`log-format` or `unique-id-header`. I'm guessing incrementing the value
happens after `http-request` is processed, but before log-format or
unique-id-header.
Hi,
I'm seeing a very sporadic issue (every few days) in a TCP mode proxy
and I'm at loss what could be causing it.
After some time, haproxy is unable to establish a connection with the
backend server. 2 is the configured connect timeout. I can't see any
exhausted resources in haproxy
Hi Patrick,
On Sat, Jan 25, 2014 at 03:40:38AM -0500, Patrick Hemmer wrote:
This patch does appear to have solved the issue reported, but it
introduced another.
If I use `http-request add-header` with %rt in the value to add the
request ID, and then I also use it in `unique-id-format`, the 2
On Sat, Jan 25, 2014 at 10:43:28AM +0100, Willy Tarreau wrote:
So we have no other choice but copying the ID into the session or HTTP
transaction, since it's possible to use it several times. At the same
time, I'm wondering if we should not also increment it for new sessions,
because for
*From: *Willy Tarreau w...@1wt.eu
*Sent: * 2014-01-25 04:43:28 E
*To: *Patrick Hemmer hapr...@stormcloud9.net
*CC: *haproxy@formilux.org haproxy@formilux.org
*Subject: *Re: haproxy duplicate http_request_counter values
Hi Patrick,
On Sat, Jan 25, 2014 at 03:40:38AM -0500, Patrick Hemmer wrote:
On Sat, Jan 25, 2014 at 05:05:07AM -0500, Patrick Hemmer wrote:
Sounds reasonable. Running through it in my head, I can't conjure up any
scenario where that approach wouldn't work.
Same here. And it works fine for me with the benefit of coherency
between all reported unique IDs.
I'm about to
Hi,
On Sat, Jan 25, 2014 at 10:12:50AM +0100, pechspilz wrote:
Hi,
I'm seeing a very sporadic issue (every few days) in a TCP mode proxy
and I'm at loss what could be causing it.
After some time, haproxy is unable to establish a connection with the
backend server. 2 is the
Hi Ricardo,
On Thu, Jan 09, 2014 at 10:35:46AM +0100, Ricardo wrote:
Whit this conf, the result of the cookies passed to the client is this:
Set-Cookie: JSESSIONID=1EAA38A1BD418EB1A79DD64E1AE9A407; Path=/; HttpOnly
Set-Cookie: WEBSERVERID=B|Us5p2|Us5p2; path=/
But I'm looking for secure
On Tue, Jan 21, 2014 at 09:04:12PM -0500, Patrick Hemmer wrote:
Personally I would not like that every server is considered down until
after the health checks pass. Basically this would result in things
being down after a reload, which defeats the point of the reload being
non-interruptive.
I
On Thu, Jan 23, 2014 at 04:19:35PM -0700, Jim Freeman wrote:
Using haproxy-1.5-dev19 on Debian/Wheezy, and haproxy-1.5-dev21 on
CentOS6.2, killing haproxy with SIGQUIT gets me nothing in the system logs.
SIGHUP gets proxy/server status info into the logs just fine.
I'm using them the same
Since the man page description says the output for both goes to the logs, I
thought that would be the place to look:
- SIGHUP
Dumps the status of all proxies and servers into the logs. Mostly used for
trouble-shooting purposes.
- SIGQUIT
Dumps information about memory pools into the logs. Mostly
On Sat, Jan 25, 2014 at 10:15:30AM -0700, Jim Freeman wrote:
Since the man page description says the output for both goes to the logs, I
thought that would be the place to look:
- SIGHUP
Dumps the status of all proxies and servers into the logs. Mostly used for
trouble-shooting purposes.
Ah - tragic :-) - it's been handy for us to search/share our system stuff
using log analytics ...
Thanks again, and again, and again ...
On Sat, Jan 25, 2014 at 10:18 AM, Willy Tarreau w...@1wt.eu wrote:
On Sat, Jan 25, 2014 at 10:15:30AM -0700, Jim Freeman wrote:
Since the man page
Confirmed. Testing various scenarios, and they all work.
Thanks for the quick patch :-)
-Patrick
*From: *Willy Tarreau w...@1wt.eu
*Sent: * 2014-01-25 05:09:09 E
*To: *Patrick Hemmer hapr...@stormcloud9.net
*CC:
On Sat, Jan 25, 2014 at 03:14:00PM -0500, Patrick Hemmer wrote:
Confirmed. Testing various scenarios, and they all work.
Thanks for the quick patch :-)
Cool, thanks for the quick feedback :-)
Willy
16 matches
Mail list logo