Is there any params for RedisCluster __init__, to let redis know when did idle client connection should be kicked out

[yanchidezhang]

Hi people,

Here is my scenario, when i init about 40 RedisCluster instances(it is neccessary for me) and do a huge concurrent operation, I found a lot idle client connections on server-side, even i stopped concurrent operation, idle connections won't be released automatically. I tried use max_connections to prevent volume of connections from explosive increasing. But, i think the connections which idle for ages should be kicked out. Is there any possible way to achieve this by setting any params(which i might know yet, or it doesn't realized yet) to RedisCluster

According to redis official document, I noticed that idle client connections won't be closed forever by default. SET TIMEOUT xxx is a good solution on server-side, to let redis know when did it need to kick off the idle client. But I am earger to have a client-side solution.

https://redis.io/docs/reference/clients/

I didn't see any realization in codes that RedisCluster that allows user to handle idle_timeout (like Jedis)

Will it be supported in the future releases? I'd appreciatie if somebody can anwser this

Best, Yanchi

[yanchidezhang]

issue which my be related https://github.com/redis/redis-py/issues/445

[Grokzen]

@yanchidezhang No there is no client setting or feature to do this in this library or to my knowledge the versions that redis-py that is supported by us here.

The main problem usually with these things is that you have to implement a threaded connection tracking or reaping feature that runs alongside the normal code flow. This is not done by default and we use the connection recycle model that redis-py use in order to not break our clients. So tweaking your max connections is the only way you have to controll some part of the client side.

You can't set a timeout that will be triggered in a non blocking or unthreaded fashion. It might be possible in the asyncio version in upstream redis-py later versions when this code base was merged into there.

Also comparing to Jedis is difficult as the core language features and how things is implemented is different between languages, things they can do there might not be possible here.

But if you really want to have something you need to sort it out with threads but be careful as you are messing around with code that is not always suitable or 110% stable in a threaded environment and you could face consequences or issues with that solution rather then just either recreating your cluster object every so often to clear things out, or just live with max_connections and let the library do and work the way it was intended to work.

One thing i can say for sure, is that i will not make any effort or put time into investigating any option into this or adding this as a feature, mostly because cluster support is not in redis-py itself and i urge people to upgrade dependencies and move up there instead

[yanchidezhang]

@Grokzen Thanks for your quick and comprehensive response! That quite helps.