* 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
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.
