<div>
            <div><span>I don't want to have a single load balancer because I want to avoid a single point of failure.  And we'll be pushing enough data that it would be a huge bottleneck.</span></div><div><span><br></span></div><div><span>A failed node will not receive new requests, but when the requests that <i>were</i> sent to it fail I'd like to retry those automatically instead of having errors bubble up to our application.<br>
                </span>
                <span></span>
                
                <p style="color: #a0a0a0;">On Thursday, April 7, 2011 at 8:17 PM, Wilson MacGyver wrote:</p>
                <blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;">
                    <span><div><div>use haproxy to ping each of the riak node. and remove nodes that<br>aren't responding is<br>what we did.<br><br>we use a single haproxy instead of 1 per application server.<br><br>On Thu, Apr 7, 2011 at 9:47 PM, Greg Nelson <<a href="mailto:grourk@dropcam.com">grourk@dropcam.com</a>> wrote:<br><blockquote type="cite"><div>Hello,<br>I have a simple three node cluster that I have been using for testing and<br>benchmarking Riak.  Lately I've been simulating various failure scenarios --<br>like a node going down, disk going bad, etc.<br>My application talks to Riak through an haproxy instance running locally on<br>each application server.  It's configured to round-robin over the nodes in<br>the cluster for both HTTP and PBC interfaces, and uses the HTTP /ping health<br>check.  I assume this is a rather typical setup.<br></div></blockquote><br>-- <br>Omnem crede diem tibi diluxisse supremum.<br></div></div></span>
                
                
                
                
                </blockquote>
                
                <div>
                    <br>
                </div>
            </div>
        </div>