Handling Closing Idle Client

[debasish]

Hi -

After a period of 300 s (the default) inactivity, Redis server closes
the idle client. What's the expected behavior of a Redis Client if it
issues a command to the server after the idle period when the server
does not have the active client connection ? Should the Redis client
give an error or try to reconnect ?

Thanks.
- Debasish

[Brian Hammond]

The Node.js client tries to use keep alive but will also auto reconnect, for what it is worth.

[debasish]

How do you track on the client that the server has closed an idle
client ? With Java, the socket to the server does not give me any info
regarding it. A read from the socket fails, but before that I am doing
a write for the Redis command which goes through successfully in the
output stream of the socket ..

Thanks.

On Jul 17, 2:40 am, Brian Hammond <br...@fictorial.com> wrote:
> The Node.js client tries to use keep alive but will also auto reconnect, for what it is worth.
>

[Joubin Houshyar]

Yes, that's the issue with Java.  This introduces the ambiguous situation where on read errors (which do detect broken connections) you are not sure if your (destructive/write) command on write actually went through or not, which complicates reconnect strategies.  Pipeline has the same issue, but magnified by number of in-flight commands.

One approach is to always issue a PING before a destructive command on writes. This takes care of most situations, but the worst case scenario remains where Redis faults after a PING/PONG, (some write cmd) ..., where we (again) don't know whether the command was processed or not, since our defensive PING did get a PONG.

JRedis uses heartbeats.  Somewhat defeats the purpose of timeout on the server config but it does address above issue.  Connections can not time out, and faults are fairly clearly server/net related.  Still does not address the issue of ambiguous states completely, but at least here we can be *more* certain that a fault on read is definitively _not_ due to idle disconnect and it is very _unlikely_ that the write was processed on the server.  

Both have some ~minor performance impact.

/R

[Joubin Houshyar]

Found another (better) method but introduced latencies are
problematic. Ping test occasionally doesn't catch the drop.

http://gist.github.com/479942

[Joubin Houshyar]

This is a fault tolerant connection. Try firing up a few instances of
the class and then randomly shutdown redis, wait for a few seconds and
then and bring it back up.

Note that this version does not delay (delay is set to 0) after
sending INCRs to force timeouts, since a simple benchmark of the
impact of the connection monitoring is made: down by an order of
magnitude compared to JRedis performance.

http://gist.github.com/480022

If reliability trumps performance, the above is a viable option.

/R

[Joubin Houshyar]

A little bit of tinkering and the performance is now par with expected
throughput rates. I've updated the previous gist.

This latest mod was very effective. and I would think this method is
*preferable* to a keep-alive daemon: it is effectively the same thing
but much simpler and without any need for managing additional threads
per connection. Thank you for starting this thread! ;) I'll do more
tests and may switch to this approach.