example screen shot of new last check field

Screen shot of some different states of the new "last check field" from Krzysztof Olędzki

http://imgur.com/LabZH - shows response time and http status

looks great! Thanks to all 1.4 developers and sponsors for their efforts.

$ haproxy -vv
HA-Proxy version 1.4-dev3 2009/09/23
Copyright 2000-2009 Willy Tarreau <w#1wt.eu>

Build options :

   TARGET  = linux26
   CPU     = generic
   CC      = gcc
   CFLAGS  = -m64 -march=x86-64 -O2 -g
   OPTIONS = USE_STATIC_PCRE=1

Default settings :

   maxconn = 2000, bufsize = 16384, maxrewrite = 8192, maxpollevents = 200

$ gcc version 4.4.1 20090725 (Red Hat 4.4.1-2) (GCC)

On 9/23/09 4:15 PM, Willy Tarreau wrote:
> Hi all !
>
> After approximately one month, we managed to gather enough features
> and fixes to release a new development version.
>
> First, a quick spot on the fixes. Dmitry Sivachenko provided a
> patch to fix build failures on FreeBSD. It was also noticed that
> the tarpit feature did not work anymore in 1.4-dev2, which is now
> fixed. That's all for the regressions in 1.4-dev2. That means that
> 1.4-dev2 has been pretty stable for the ones who used it.
>
> Now the shiny new features.
>
> First, everyone on the list has seen Krzysztof Oledzki's patch
> to report precise health check status on the stats interface.
> It's really nice because with this, you don't only see that a
> server is dead, you see what steps of the test it succeeded or
> failed, and in how much time. This will be particularly helpful
> for persons who have to configure HTTP health checks on URLs
> they're not exactly certain (for hosted customers, etc...).
> I invite all stats user to try this and to report ideas on how
> to improve it (I'd personally like to get captures of last
> requests and responses which changed the service's state, but
> it can take quite some time to implement). Some people might
> have other ideas.
>
> Second, I've been working on adapting the internals to evolve
> towards multi-layering and keepalive. We've reached the point
> where unix and TCP sockets share the same code, and where it
> is possible for a processing to be embedded within a task, be
> it the one which handles the session or another one.
Received on 2009/09/24 09:28