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]
