Hi Willy,
On Saturday 10 July 2010, Willy Tarreau wrote:
Actually, I am not that much interested in the patch per-se, I would just
like to check the body of the check-response and compare it to a string
for more reliable checks.
It's what the patch does.
Hmmm, I thought it was bigger...
Hi Anze,
On Mon, Jul 12, 2010 at 09:28:09AM +0200, Anze wrote:
Hi Willy,
On Saturday 10 July 2010, Willy Tarreau wrote:
Actually, I am not that much interested in the patch per-se, I would just
like to check the body of the check-response and compare it to a string
for more reliable
Hi Anze,
On Fri, Jul 09, 2010 at 01:48:12AM +0200, Anze wrote:
Indeed it never made it in. Each time I look at it, I realize that
cleaning it up and fixing it will take more time than what I have
available to work on it :-/
I can understand that completely. :)
Actually, I am not
Indeed it never made it in. Each time I look at it, I realize that
cleaning it up and fixing it will take more time than what I have
available to work on it :-/
I can understand that completely. :)
Actually, I am not that much interested in the patch per-se, I would just like
to check the
Hi all,
We have tried upgrading our haproxy version to 1.4.8 and found than this
configuration setting fails:
http-check expect string check_is_ok
with message:
'http-check' only supports 'disable-on-404'
I guess the patch never made it to stable (yet?). Are there any plans to add
it to
Hi all,
Le Mardi 16 Mars 2010 21:35:10, Willy Tarreau a écrit :
I'm now gathering my changes and committing your patch with the small
fixes above. That way we can concentrate on ECV.
I've played a little with this commits.
I added some traces to see what happens when a timeout occurs and
Le Mercredi 17 Mars 2010 21:12:45, Willy Tarreau a écrit :
(...) I don't
agree with restting the buffer or even considering we have an error
when a session does not close, because it is a regression. For instance,
all people using HTTP/1.1 checks will see a problem here.
hey right, I suddenly
diff -ur haproxy-1.4.1/include/types/proxy.h haproxy-1.4.1-ecv-test/include/types/proxy.h
--- haproxy-1.4.1/include/types/proxy.h 2010-03-04 22:39:19.0 +
+++ haproxy-1.4.1-ecv-test/include/types/proxy.h 2010-03-15 10:15:40.0 +
@@ -137,6 +137,8 @@
#define PR_O2_MYSQL_CHK
Hi Nick,
Thanks for the update. I've quickly reviewed it and noticed
some of the issues of the initial ECV patch (though I don't
remember them all, I'll have to dig into my mailbox). I'm
putting a few examples below.
What I can propose you is to proceed in 3 phases :
- I will try to extract
On Tue, Mar 16, 2010 at 06:22:09PM +0100, Willy Tarreau wrote:
What I can propose you is to proceed in 3 phases :
- I will try to extract the two features from your patch
(response reassembly and ECV), and apply the first one
to next 1.4.
OK, your code was clean and the two parts
Hello Willy.
On 8 March 2010 21:25, Willy Tarreau w...@1wt.eu wrote:
On Mon, Mar 08, 2010 at 04:32:54PM +, Nick Chalk wrote:
Attached is a patch against v1.4.1. It contains the updated ECV patch,
and the hacks to work around check responses that span multiple
packets.
At first glance, it
Hello Willy.
On 3 March 2010 20:31, Willy Tarreau w...@1wt.eu wrote:
OK that's perfect then. If you don't manage to sort out your issue
with small packets, do not hesitate to post your work in progress
to the list, it often helps a lot to work iteratively.
The small-packet problem turned out
Hello Willy.
On 2 March 2010 21:45, Willy Tarreau w...@1wt.eu wrote:
If your quick ack already works for one single check, then simply
allocate a buffer for each server in cfgparse.c, and have the
checks functions use that server-specific buffer instead of
trash.
Thanks for the pointer. I've
On Wed, Mar 03, 2010 at 08:12:09PM +, Nick Chalk wrote:
Hello Willy.
On 2 March 2010 21:45, Willy Tarreau w...@1wt.eu wrote:
If your quick ack already works for one single check, then simply
allocate a buffer for each server in cfgparse.c, and have the
checks functions use that
Hello Willy.
On 25 February 2010 20:25, Willy Tarreau w...@1wt.eu wrote:
On Mon, Feb 15, 2010 at 10:05:57AM +, Nick Chalk wrote:
On 13 February 2010 10:40, Willy Tarreau w...@1wt.eu wrote:
Indeed, with MSG_PEEK we have no way to tell the connection was closed.
For the time being, I've
Hi Nick,
On Tue, Mar 02, 2010 at 12:25:06PM +, Nick Chalk wrote:
Hello Willy.
On 25 February 2010 20:25, Willy Tarreau w...@1wt.eu wrote:
On Mon, Feb 15, 2010 at 10:05:57AM +, Nick Chalk wrote:
On 13 February 2010 10:40, Willy Tarreau w...@1wt.eu wrote:
Indeed, with MSG_PEEK we
Hi Nick,
On Mon, Feb 15, 2010 at 10:05:57AM +, Nick Chalk wrote:
Hello Willy, Krzysztof.
On 13 February 2010 10:40, Willy Tarreau w...@1wt.eu wrote:
On Fri, Feb 12, 2010 at 05:47:41PM +0100, Krzysztof Ol??dzki wrote:
There are several issues with the fix:
- we need to check if
Hello Willy, Krzysztof.
On 13 February 2010 10:40, Willy Tarreau w...@1wt.eu wrote:
On Fri, Feb 12, 2010 at 05:47:41PM +0100, Krzysztof Olędzki wrote:
There are several issues with the fix:
- we need to check if connection is not closed, as it is pointless to
use MSG_PEEK and restarting
On Fri, Feb 12, 2010 at 05:47:41PM +0100, Krzysztof Ol??dzki wrote:
There are several issues with the fix:
- we need to check if connection is not closed, as it is pointless to
use MSG_PEEK and restarting such check if there is no more data we are
able to read
Indeed, with MSG_PEEK we
On Wed, Feb 10, 2010 at 10:56:14PM +, Nick Chalk wrote:
Thanks Willy, Krzysztof.
2010/2/10 Willy Tarreau w...@1wt.eu:
Did you managed to fix the several remaining issues which could cause
it to crash the process ?
I believe so, following Cyril Bonté's suggestions last week. I'm
20 matches
Mail list logo
