Connection error read eof error returned

[philjohn]

Every now and then I'm getting an error returned:

Connection error read eof [addr: 127.0.0.1:6379]

It can sometimes not come along for 10+ minute, and other times appear a few times in a row.

[toymachine]

this will happen if for some reason the connection with redis was dropped. you will only find this out on the next execute, so you should retry, and the connection will be created again.

[toymachine]

check you redis server config to see if it will drop client connections after some timeout

[philjohn]

Thanks for the response, I've disabled that now and I'll see how it goes.

From looking at the code it appears to be using persistent connections (big + for libredis vs any other client library), so it would be useful if it was able to handle an EOF from a socket and re-open it transparently.

I'll try to hack something in myself, but my c is very rusty (and somewhat limited) :)

[toymachine]

Yes you are right, it uses persistent connections by default, this is by design. also not handling connection failures automatically is by design, although an option for 'auto-reconnect' would be nice (but only at the start of the 'execute' phase, e.g. if you find EOF halfway writing commands, it should abort as the state is inconsistent). Half read results (due to EOF on any of the servers) are fine, but should be reported

There are a number of design decisions that make more sense if you know why I've created it, e.g. I am a senior dev at Hyves.nl, the Netherlands largest social network (250M pageviews/day). So important for us:

• persistent connections
• speed (possibly at the expense of nice API abstractions), hence the somewhat raw API :-)
• no automatic error handling, we want to report all error conditions and not automagically re-try while there might be underlying problems in our 3000+ machine server park :-)
• ability to query many Redis servers at the same time with timeouts (hence the 'batch' and 'execute' API's.

[philjohn]

Good to see that it's used heavily as we're evaluating it for a busy SaaS webapp.

If anything, the "raw" API is nice as it's easier to emulate some commands when working with multiple servers (sUnion/Intersect/Diff) and batching up a load is lightning quick.

You're right that the only time you'd want to reopen would be at the very start when initially getting the connection.

[philjohn]

Just one more thing, when using get_connection is it possible to identify if there was a problem with the connection (server down, connection closed etc)? It always seems to return a _Libredis_Connection class, even when I've given it a non-existent server address.