External pool

[jinty]

Allow the pool implementation to be overridden and provide status. Minimum required to support:
https://github.com/vanguardistas/van.resumelb

[jimfulton]

Much thanks. This was a great PR. Sorry I took so long to merge it.

[jinty]

no worries, thanks for zc.resumelb!

I prefer slow acceptance of pull requests than bad software any day of the week.

[jimfulton]

:)

BTW, I'm working on a resume-less pool that just selects workers with minimum backlogs.

If you have anything I should consider instead... :)

It turns out that we have lots of smaller applications where resumes get in the way, but having a simple ZooKeeper-aware back-end LB is very useful.

[jinty]

On Wed, Feb 11, 2015 at 01:43:10PM -0800, Jim Fulton wrote:

:)

BTW, I'm working on a resume-less pool that just selects workers with minimum backlogs.

If you have anything I should consider instead... :)

It turns out that we have lots of smaller applications where resumes get in the way, but having a simple ZooKeeper-aware back-end LB is very useful.

We don't really need the resumes, but I've never found that it "got in
the way".

I am still using my own pool implementation:

https://github.com/vanguardistas/van.resumelb

Not sure if that fits into "something else you should consider" but
it has been extremely useful and stable. It makes upgrades very smooth
as we can switch users from one version to another more or less
instantaneously.

In future, I may need to work in this area again to start sending
different requests to more specialized backend servers. So I will end up
classifying on:

(service, version, classifier)

I.e. running multiple versions of multiple services behind a singe
resumelb. I suppose you could run multiple resumelbs, one per service,
but that may make the system harder to run/monitor.

Brian Sutherland

[jimfulton]

Ah right. Well, I've added a simple class-less pool that does least-connection load balancing.