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.
- Add asking to cluster commands
- Make jedis cluster return connection to original pool
- Add tests for MOVED and ASK cluster responses
- Refactor connection handler to recalculate connections based on slots
This commit makes the first usable version of Jedis along with Redis Cluster
multi)
* BinaryClient / BinaryJedis : added feature to reset its state
(watched, multi)
* JedisPool / JedisSentinelPool : calls new feature (reset state) when
Jedis object returns to pool
* Unit Test included
* In BinaryJedis.multi(TransactionBlock), multi & exec already fired before exception occured, so sending discard has no effect, and made another error
** add unit test (error inside TransactionBlock)
*** Transaction with error - Redis discards transaction automatically (execabort)
*** Transaction with error - Redis doesn't roll back (force to execute all)
* increase sentinel instance to test JedisSentinelTest
** clear() called, slave promoted to master (slave of no one), New
Sentinel force to restore it (demote) -> slave is not reusable
* ipv6 applied at Redis 2.8 -> localhost / 127.0.0.1 / ::1 is now all same
* Makefile: sleep some time for launch each sentinel (workaround to sentinel's issue)
** issue to sentinel leader vote: https://github.com/antirez/redis/issues/1419
*** sentinel may confused to vote with sentinels launched approximately same time
* if RedisInputStream().read() at Protocol.processBulkReply() returns
-1, it runs with unexpected behavior
* fix: check and if return value is -1, it throws
JedisConnectionException with message "server has closed the connection"
** prevent unexpected behavior, specially ArrayIndexOutOfBoundException
*** calls System.arraycopy() with length = -1 (cause limit = -1) at
RedisInputStream.read()
add pubsub unit test scenario : client-output-buffer-limit exceed
* Redis warns event(disconnect client) to their log, and suddenly
disconnected connection
** http://redis.io/topics/clients -> Output buffers limits
** so test expects JedisConnectionException with proper message
* remove FIXME sleep codes for Sentinel related tests
** add functions for Sentinel tests (JedisSentinelTestUtil)
*** waitForSentinelRecognizeRedisReplication
*** waitForNewPromotedMaster
*** waitForSentinelsRecognizeEachOthers
**** TODO: there're no command for sentinel to list recognized sentinel
**** sleep 5.5 sec (sentinel pings to master every 5 sec)
* set HostAndPort class to public(no longer inner) class
** reason: We cannot know pool's current master if HostAndPort class is
private inner class / HostAndPort classes are duplicated (main/test)
** make getter method and parameterized constructor
*** set fields once, get anytime
* Now Pool.initPool() call closeInternalPool(), instead of destroy()
** calling destroy() in Pool.initPool() may have side effect, and JedisSentinelPool did
* modify unit test to test failover twice (needs +1 slave)
** modify configurations for additional slave
This test will set up and get a master from a Redis master slave pair being
watched by 2 Sentinels. It pings the master, segfaults it, asks the pool for
another connection and makes sure it can ping it.
This commit also restores the pom.xml file's scm information back to
xetorthio and adds the default Sentinel port to the Procotol.
Given a master name and a set of sentinels this pool will subscribe to the
Sentinel notifications about master changes (+switch-master) and
re-establishes the pool to the new master when one is announced.
