On Fre 02.10.2009 06:48, Willy Tarreau wrote:
Hi Aleks,

On Thu, Oct 01, 2009 at 10:06:12PM +0200, Aleksandar Lazic wrote:
(...)
>For a developper, it means that the door is open to try to implement
>internal services running as "applets" (eg: a CLI) and multi-layer
>protocols. It's the right moment to try again to merge some
>asynchronous SSL or FastCGI converters into haproxy. For sure there
>will be some annoying issues, but probably not total showstoppers as
>were encountered in the past. As a proof of concept, I have changed the
>stats socket to use this new mechanism. The code looks easier to read,
>and above all it allows interactive mode with a basic command line
>interface and the ability to batch multiple commands at once.

do you mean this file

haproxy-1.4-dev3/src/dumpstats.c

Yes, the stats_io_handler() function, precisely.

Ok thanks.

Maybe you have draft document about the "applets"?

Not yet, but I have a debugging patch to replace the stats with an
"echo" function, with various flavors (char, line, block). If you're
interested, I can send it to you. I know it's slightly buggy because
last bugs were fixed in the stats code while I wasn't developing on
this patch anymore, but it gives the basic idea.

[snipp]

Hm so if I want to add ajp,fcgi, ... protocol I think I will need a
buffer for the 'header' and for the content.

Do you think it is the right time to add it to haproxy or should I wait
until the 'interface' is more ready?

Do you plan to make it possible as dynamic librarys?

I'am quite interested to add a distributed session setup with

Tokyo Cabinet http://1978th.net/tokyocabinet/
Tokyo Tyrant http://1978th.net/tokyotyrant/

Right now, a huge stickiness rework is being funded and performed by
Exceliance and Loadbalancer.org. Two steps are planned, the first one
consisting in rearchitecturing the internals, and the second one,
consisting in finding how to transfer data between processes (old to
new at first, then possibly permanent sync).

I think we should wait for the first step to be complete and discuss
the ideas then. After some time thinking on the matter, I feel like we
never need to sync large amounts of LBs together and that having
full-mesh communications would be more than enough and would ensure
synchronization without the overhead of something like TT. Also, the TT
server would have itself to be backed up and synchronized, resulting in
a more complex setup for small deployments. But right now these are
just feelings, neither arguments nor directions to take.

Ok,I will wait for this.
Is there a 'open' discussion about this issue?!

For this a question to the list-users

Which balance methode is the most used one?

From what I have seen in configs I receive in private or find on the
net, the roundrobin is the clear winner, with the other ones used only
when there is a real reason for this.

So no stickyness on the loadbalancer, so the most application use the
cookies and shared storage for the sessions, right.

Does anybody use the appsession feature?

I know that some people use it, as I have received some configs where
it was enabled and people had good reasons for this. I remember that
the main reason was the same you had when you developed it : support
for some very specific browsers which don't support cookies at all (eg:
WAP or things like this).

This was my first 'session based methode' to make it HA ;-).
If so less user use it I'am not sure if it is worth until the 'global'
handling is designed.

Maybe other people here are other reasons ?

Maybe ;-)

BR

Aleks

Reply via email to