Large number of :lamina/drained! errors with HTTP client

[Andrew Cholakian]

Zach, I'm curious as to the meaning of a :lamina/drained! . It's not quite reproducible consistently, but I seem to get a large number  of them from time to time (as in all of engulf's requests may have them). Is there an intended way to recover from a drained state? I am using keep-alive with the client if that helps to know.

Restarting the app usually fixes it though.

[Andrew Cholakian]

I should mention that it's not *always* a large number. One recent run had it occur only 26 times out of 20000. Sometimes every request returns that however. I'm running the latest snapshot. This is based off engulf's beta1 release.

[Zach Tellman]

It's an indication that the connection has been closed, so attempts to
read a response from the channel fail because it is drained.

If you add {:retry? true} to the options, does it stil happen?

[Andrew Cholakian]

Ah, that makes sense. I'm a bit surprised that it recovers some of the time given that. Would that also happen if the timeout is exceeded? (I generally set it at a fairly low 5000 ms).

For engulf I'll try simply ensuring the client's closed and using a new client for the pool. I can't use retry? as I need to record errors as such.

Thanks for the response Zach. I'm going to try and integrate some of my knowledge of the client into the Wiki later in the week. Stuff like the and soLinger are pretty nice to know about.

[Zach Tellman]

If the connection is closed, then the client will automatically
reconnect, so only requests made during the disconnected period will
fail. Previously, the retry behavior was automatic, but since this
could cause issues with non-idempotent calls I decided to let the
failures fall through by default. The timeout behavior is unrelated.

I think it's valuable to be able to turn off the retry behavior, but I
may have made the wrong decision in turning it off by default; it's
making implementation details leak out into the surrounding code.
This isn't an "error" in the sense you mean it, but it's an easy thing
to get confused about, and I don't think people should have to wrestle
with this in the default case.

I'm going to change the default setting in the latest Lamina snapshot.
If you have any thoughts on this, I'd be happy to hear them.

Zach

[Andrew Cholakian]

On Wed, Aug 15, 2012 at 11:59 AM, Zach Tellman <ztel...@gmail.com> wrote:
> If the connection is closed, then the client will automatically
> reconnect, so only requests made during the disconnected period will
> fail. Previously, the retry behavior was automatic, but since this
> could cause issues with non-idempotent calls I decided to let the
> failures fall through by default. The timeout behavior is unrelated.

Glad to hear it.

> I think it's valuable to be able to turn off the retry behavior, but I
> may have made the wrong decision in turning it off by default; it's
> making implementation details leak out into the surrounding code.
> This isn't an "error" in the sense you mean it, but it's an easy thing
> to get confused about, and I don't think people should have to wrestle
> with this in the default case.

Oh, gotcha. So in other words, if a server is simply enforcing a
keep-alive timeout drained may pop up. Yes, definitely not an error.
I'll add retry in then. Thanks!

> I'm going to change the default setting in the latest Lamina snapshot.
> If you have any thoughts on this, I'd be happy to hear them.

Nope, I think you answered my questions. Thanks Zach! I think this
makes a lot of sense, I'll add retry? in explicity anyway.