Oleg, Thanks for the reply. Ideally the "spray" approach is what I'm looking for.
Dan On Sat, May 28, 2011 at 11:47 AM, Oleg Kalnichevski <[email protected]> wrote: > On Thu, 2011-05-26 at 20:17 -0400, Dan Checkoway wrote: >> Hello, >> >> I'm looking for recommendations on best practice for client side >> failover...with pooling/keepalive. I've been rolling my own, but I'm >> migrating to HC and could use some advice. Here's what I'm faced with >> requirements-wise: >> >> 1. My app is running on appserver01...n, and it's using HttpClient to >> talk to a web service that's running on ws01...n. >> >> 2. Unfortunately, my hands are tied and I can't throw a VIP/LB in >> front of ws01...n (wouldn't that just be too easy), and I can't use >> round-robin DNS either (I found MultihomePlainSocketFactory, but it's >> deprecated anyway). I need to address the ws* boxes individually. >> >> 3. A key requirement is that I take advantage of persistent HTTP >> connections (keepalive). >> >> 4. When appserverN needs to talk to ws*, it should pick a node at >> random (poor man's load balancing). If that node is down, it needs to >> fail over to another node, without the calling code knowing or caring >> what happened. >> >> Is there a reliable existing pattern or example out there somewhere, >> or -- better yet -- something in HttpCore or HttpClient that provides >> this type of pooling with failover strategy out of the box? I would >> rather steal or adapt good code than reinvent this wheel... >> >> Any tips? >> >> Thanks, >> Dan >> > > Dan > > HttpClient 4.1 supports fail-over based on multiple DNS entries (so > called multihoming) out of the box. This is actually the reason > MultihomePlainSocketFactory got deprecated. > > Does your application need to support fail-over to a standby node only, > or you actually need to be able to 'spray' the traffic across multiple > nodes? > > Oleg > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
