Should Hystrix replace existing JDBC/HTTP connection pools, or delegate to them?

[ant...@vinland.me.uk]

Hi there,

Many applications use connection pools for both HTTP and JDBC calls for resiliency. But using and configuring these 2 types of pools is very different. This duplicates the complexity of implementing resiliency patterns that are common to both - such as timeouts, retries, caching / alerting fallbacks, circuit breaking, and monitoring.

To my mind Hystrix offers common approaches of configuring and implementing these same resiliency patterns for both HTTP and JDBC calls.

My questions are:

1. Could Hystrix theoretically replace existing HTTP and JDBC connection pools entirely?
2. If so, what are the pros and cons of doing so?

Replacing them entirely reduces the world of complexity that surrounds these connection pools - with their attendant timeout and validation query properties etc. However I am hazy about how Hystrix could "keep alive" JDBC / HTTP connections - and therefore avoid expensive connection setup costs - without delegating to existing libraries specialized for these tasks.

For context I have a DropWizard app, which uses Tomcat DBCP for its JDBC connection pool and Apache HttpClient for its HTTP connection pools.

Thanks! Also asked here: http://stackoverflow.com/questions/30768990/should-hystrix-replace-existing-jdbc-http-connection-pools-or-delegate-to-them

Anthony

[Matt Jacobs]

I think there is value in Hystrix being agnostic of what exactly the run() method does.  This way, it has general-purpose abstractions that apply to many situations, such as wrapping HTTP/JDBC calls.  I do agree that having a separation between the general-purpose Hystrix layer and the specific HTTP layer adds complexity because both require configuration separately. You can certainly build an HTTP client which does retries/warming/connection pooling (at Netflix we use Ribbon), but this would be something that lives outside of Hystrix.

[ant...@vinland.me.uk]

Dear Matt,

Thanks so much for your response. So it sounds like layering Hystrix on top of full featured HTTP / JDBC clients isn't a silly idea anyway :)

I guess the "value in Hystrix being agnostic of what exactly the run() method does" is that you can logically switch the type of connection to use as requirements change - say from a web request to a database call - without affecting the resiliency architecture and safeguards that Hystrix provides.... and this added value outweighs the extra config complexity?

If so adding Hystrix to a Dropwizard app shouldn't be as intrusive as I thought. I'll take a look at Tenacity to see how they've done it.

Best wishes,

Anthony.