[prev in list] [next in list] [prev in thread] [next in thread] 

List:       haproxy
Subject:    Re: redispatch request if 502 received
From:       Dustin Moskovitz <moskov () asana ! com>
Date:       2010-08-25 19:19:40
Message-ID: AANLkTim9PGFzvb0i9A7FY9FUDv_KRFBHujm6KWspptE3 () mail ! gmail ! com
[Download RAW message or body]

Perhaps, but we are running nginx on the same physical boxes as the
webservers, not in front of haproxy, so it is not in a position where it can
retry the request on a different server. Retrying the request on the same
server won't help with most classes of problems.

client->open internet->haproxy->internal network->nginx->webserver



On Wed, Aug 25, 2010 at 12:16 PM, Willy Tarreau <w@1wt.eu> wrote:

> On Wed, Aug 25, 2010 at 12:06:32PM -0700, Dustin Moskovitz wrote:
> > Thanks for all the input guys. Sounds like haproxy is the wrong place to
> > solve the problem, so we've instead decided to remove nginx from the
> > equation (which was only providing gzip capabilities that we can
> implement
> > directly in our webserver). Thus, requests failing on the webserver will
> > actually result in disconnects, which will allow haproxy to redispatch
> the
> > request to a new server.
>
> Well, I may be wrong, but I *think* that when nginx acts as a caching
> proxy, it is able to retry. You might want to check this and perhaps
> reintroduce it. Haproxy+Nginx are generally known to form a complete
> and reliable solution together.
>
> Regards,
> Willy
>
>

[Attachment #3 (text/html)]

Perhaps, but we are running nginx on the same physical boxes as the webservers, not \
in front of haproxy, so it is not in a position where it can retry the request on a \
different server. Retrying the request on the same server won&#39;t help with most \
classes of problems.<div>

<br></div><div>client-&gt;open internet-&gt;haproxy-&gt;internal \
network-&gt;nginx-&gt;webserver<br><br></div><div><br></div><div><br><div \
class="gmail_quote">On Wed, Aug 25, 2010 at 12:16 PM, Willy Tarreau <span \
dir="ltr">&lt;<a href="mailto:w@1wt.eu">w@1wt.eu</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex;"><div class="im">On Wed, Aug 25, 2010 at 12:06:32PM -0700, \
Dustin Moskovitz wrote:<br> &gt; Thanks for all the input guys. Sounds like haproxy \
is the wrong place to<br> &gt; solve the problem, so we&#39;ve instead decided to \
remove nginx from the<br> &gt; equation (which was only providing gzip capabilities \
that we can implement<br> &gt; directly in our webserver). Thus, requests failing on \
the webserver will<br> &gt; actually result in disconnects, which will allow haproxy \
to redispatch the<br> &gt; request to a new server.<br>
<br>
</div>Well, I may be wrong, but I *think* that when nginx acts as a caching<br>
proxy, it is able to retry. You might want to check this and perhaps<br>
reintroduce it. Haproxy+Nginx are generally known to form a complete<br>
and reliable solution together.<br>
<br>
Regards,<br>
<font color="#888888">Willy<br>
<br>
</font></blockquote></div><br></div>



[prev in list] [next in list] [prev in thread] [next in thread]