* it's broken with later features, resetState()
* fixed resetState() to make it work with this PR
Conflicts:
src/main/java/redis/clients/jedis/BinaryJedis.java
src/main/java/redis/clients/jedis/Connection.java
src/main/java/redis/clients/jedis/Pipeline.java
src/main/java/redis/clients/jedis/Transaction.java
src/main/java/redis/clients/jedis/TransactionBlock.java
* Implement Closeable from Jedis, ShardedJedis with Pooled
** resources from JedisPool, JedisSentinelPool, ShardedJedis, ShardedJedisPool
* Connection class : check whether Jedis Connection is broken
** when it's time to throw JedisConnectionException, mark Connection to broken
This allows a Jedis object to participate in try-with-resources when
using Java 7+. This change is fully backwards compatible to Java 6 and
previous releases of the Jedis client.
* remove pipelinedCommands field at Connection class
** it was a risky state value
*** it was under 0 or over 0(though all commands are executed) while some situation
* remove Connection.getAll(), Connection.getAll(int except)
If Thread A calls a subscribe method on Jedis it will block on a socket read
call waiting for messages or subscription notifications. Thread B is now free
to call additional methods on JedisPubSub to change the current subscriptions
that thread A is waiting for. Essentially Thread A will do reads on the
socket and Thread B will do writes.
An issue occurs in that while Thread A is doing reads, in the
getObjectMultiBulkReply() method there is an implicit flush() call. This
means both Thread A and Thread B may do a write to the socket. Under this
situation if Thread A does a flush while Thread B is writing the internal
buffer will be corrupted. The fix is to make thread A never call flush().
This allows Thread A to be solely reads and Thread B to be solely writes.
Additionally since Thread B is sending commands, the internal pipeline count
is incremented and never decremented. So when Thread A terminates it's read
it resets the pipeline count.
---
The subscribe and psubscribe operations call setTimeoutInfinite() since they never return on their own. If the Redis server goes away without closing the connection, the connection can hang indefinitely. Turning on keep-alive will allow the connection to eventually timeout and attempt reconnection.
Note that keepalive must also be enabled on your server, see the Linux HOWTOs on how to do this.
