Specify connection timeout for blocking calls

[vdichev]

In some scenarios the TCP connection in blocking calls like brpop, blpop and brpoplpush gets stalled (netstat shows it as ESTABLISHED on the client side, but gone on the server side). In this case it would be beneficial to be able to specify a connection timeout, but blocking calls set it to infinite. I know that it's necessary in issue #108, but it should be possible to be able to set this timeout at least for calls that specify a timeout.

I suggest that for calls that specify a timeout this value (or a slightly larger one) is set for the connection timeout as well.

[marcosnils]

This is supported already

[vdichev]

I kindly suggest that until the call to "client.setTimeoutInfinite()" in https://github.com/xetorthio/jedis/blob/master/src/main/java/redis/clients/jedis/Jedis.java is gone, this issue is not resolved. If you do a quick search, you'll find that the following methods contain it:

• blpop
• brpop
• brpoplpush
• eval
• subscribe
• psubscribe

[maheshdatt]

Thanks for reopening this issue - We currently are working on a local fix. I could possibly do a PR for you to review. Let me know.

[maheshdatt]

I have forked jedis and made this change to support socket timeout - can you please check and let me know if you have any comments?

maheshdatt#1

[a8156268]

On a forced outage of redis server, our team also encountered this problem.
Redis server was restarted, while client was blocking infinite.
Is the problem being solved？

[JerryChin]

I bump into this problem today while doing some code reviewing on our codebase.

JedisPubSub which is heavily used in our system, seems also suffered from this issue.

It cripples our connection mechanism, if master is hard rebooted, the subscription thread will block forever, we're not able to switch to the newly-elected master by leveraging JedisSentinelPool, isn't a very serious problem?