I'll enter in this conversation as I've used (successfully) a load
balancer which did server-side keep-alive a while ago.
WT Hmmm that's different. There are issues with the HTTP protocol
WT itself making this extremely difficult. When you're keeping a
WT connection alive in order to send a
On Tue, Jan 12, 2010 at 11:56:38AM +0300, Dmitry Sivachenko wrote:
Imagine the following scenario: we have large number of requests from
different clients. Each client send request rarely, so no need for keep-alive
between client and haproxy.
OK I see your usage pattern now. I know three
Hi Ross,
first, thanks for bringing your experience here, it's much appreciated.
On Tue, Jan 12, 2010 at 10:27:09AM -0500, Ross West wrote:
I'll enter in this conversation as I've used (successfully) a load
balancer which did server-side keep-alive a while ago.
WT Hmmm that's different.
On 2010-01-12 23:02, Willy Tarreau wrote:
On Tue, Jan 12, 2010 at 10:05:47PM +0100, Krzysztof Piotr Oledzki wrote:
Subject: [MINOR] acl: add fe_id/so_id to match frontend's and socket's id
applied.
+fe_idinteger
+ Applies to the fronted's id. Can be used in backends to check from which
+
WT It's not only a matter of caching the request to replay it, it is that
WT you're simply not allowed to. I know a guy who ordered a book at a
WT large well-known site. His order was processed twice. Maybe there is
WT something on this site which grants itself the right to replay a user's
WT
On Tue, Jan 12, 2010 at 07:01:52PM -0500, Ross West wrote:
WT It's not only a matter of caching the request to replay it, it is that
WT you're simply not allowed to. I know a guy who ordered a book at a
WT large well-known site. His order was processed twice. Maybe there is
WT something on
6 matches
Mail list logo
