Pooled Connections shouldn't be closed if they have socket timeouts

[mircea-pop]

The following line can throw a SocketTimeoutException and in that case, the connection is marked as broken.
https://github.com/xetorthio/jedis/blob/6126d30efccb8921dcf9a03776299a504e022a3e/src/main/java/redis/clients/jedis/Connection.java#L126

Then when the close() method is called (the intention is to add the connection back to the pool), then the broken client is eventually closed:
https://github.com/xetorthio/jedis/blob/6126d30efccb8921dcf9a03776299a504e022a3e/src/main/java/redis/clients/jedis/Jedis.java#L3458

The above call will end up in the invalidateObject() method in the commons-pool2:
https://github.com/apache/commons-pool/blob/f4455dcb8afaf9ae7054589110f1082a7a8a282c/src/main/java/org/apache/commons/pool2/impl/GenericObjectPool.java#L607

which eventually will call:
https://github.com/xetorthio/jedis/blob/6126d30efccb8921dcf9a03776299a504e022a3e/src/main/java/redis/clients/jedis/JedisFactory.java#L94

This is the cause of issue #2105, where the guys see a large number of new connections. I was able to reproduce it by lowering the socket timeout.

[ganeshkumarganesan]

We are also facing the same problem. Any solution?

In our case, redis max memory limit is reached and the spike in connection (occupies more memory) led to the huge key eviction.

[yangbodong22011]

closed by #3353