On Fre 02.10.2009 22:54, Willy Tarreau wrote:
On Fri, Oct 02, 2009 at 10:19:47PM +0200, Aleksandar Lazic wrote:
Hm so if I want to add ajp,fcgi, ... protocol I think I will need a
buffer for the 'header' and for the content.
Yes, the principle is to chain two series of buffers like this :
A colleague of mine already tried to implement FCGI last year around
1.3.15 and almost succeeded, but he agreed this was awful due to the
lack of infrastructure help from haproxy's lower layers. But it was
very useful as a proof-of-concept to find out what was wrong with that
architecture and what needed to evolve. Now it should be a lot easier,
but since the same colleague also intends to work on SSL again, I'll
not hurry him too much :-)
Do you think it is the right time to add it to haproxy or should I
wait until the 'interface' is more ready?
To be quite honnest, it is a bit early but it is also what helps the
design evolve towards the right direction. If you start to implement
something now, I'm absolutely certain that you will regularly block
because of missing feature X or Y and that sometimes I won't even have
any immediate response. This is sometimes very frustrating for
everyone. But if you don't waste your time on it and just start it as a
PoC, it should be an interesting experience which can serve both of us.
I will try to make a fcgi app out of haproxy to get more familiar with
the protocol. After that I will try to add a 'applet' so that I don't
mixe 2 new issuess, learn fcgi & learn haproxy applet ;-).
So no stickyness on the loadbalancer, so the most application use the
cookies and shared storage for the sessions, right.
Oh sorry if I was not clear in my response. Since you only asked about
the LB method, I thought you were only interested in the algo.
Stickiness based on cookie insertion is almost always used with HTTP,
since it's the easiest one to deploy.
So the 'insert' and 'indirect' cookie mode ist used mostly, right?
In this case the browser gives you with the cookie the right backend.
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.
The new global handling should cover it as well (we discussed it BTW,
explaining why we need multiple matches, cookies+url for instance).
Then once the new design is ready, we can convert the appsession code
to rely on it and all the ongoing work for shared sessions will be
usable for appsessions too.
Hm, long time ago.
I will take a look into the fcgi & lsapi and come back ;-)