[OPEN-ILS-DEV] AC timeout change => [GIT] Evergreen ILS branch master updated. e08a5cbfaa14fcd386f63a5f3e29539e6be3f544

[Dan Scott]

On Tue, Jun 14, 2011 at 08:41:59AM -0400, Bill Erickson wrote:
> 
> Hi Dan,
> 
> I'd like to suggest we not make this change or at least make the
> default significantly lower.  With a 30-second timeout and a slow or
> crippled added content provider, it would not take long for the
> Apache processes to be gobbled up, leaving EG unusable.

Hmm. I guess as you say below that depends on load and the added content
provider; we've been running with timeout set to 45 seconds and using
the new OpenLibrary Read API where some requests do take a long time to
resolve (30 seconds for an ISBN with many editions is not unusual, at
least in this early stage before they've optimized their own service). I
thought that with caching integrated into added content, the idea was
that the initial request would be costly but subsequent requests would
be cached - therefore spreading out the pain.

> My preference would be to keep it at 1 w/ the understanding that
> users can raise the value if they want to take that risk.  If that's
> too aggressive for a default, I could maybe see using 2 or 3
> seconds. Anything higher is unsafe, IMO.  Of course, it depends on
> the environment.

Keeping it at 1 would be the status quo, and status quo was that I was
seeing plenty of timeouts at that setting both when we had Syndetics as
our AC provider and when we switched to OpenLibrary. 2 or 3 would
definitely be better. When I raised the default timeout value on IRC a
week or two back, the general reaction was that 1 seemed low.

If you see AC caching presenting a possible denial of service issue, then
maybe we should just eliminate the caching entirely, or overhaul it so
that it draws from a different pool of Apache processes than the main
Evergreen processes? From what you've described, it sounds like as it
currently is architected on a single-server system, a sufficient
number of concurrent AC requests would exhaust the available Apache
processes no matter what the timeout value is set to; it's less likely
to happen at 1, but still a denial of service waiting to happen.