Connection improvements
Joubin Houshyar
The gist of it is that connectors and associated helper objects (such
as response handlers, and heartbeat) are now better integrated through
Connection.Listener callback mechanism.
* ConnectionBase
This is the super for all the specialized extensions, and substantial
improvements here regarding event propagation in conjunction with
fault detection trickle down to the rest of the hierarchy. A lot of
the annoying stack trace dumps have been removed so more sensible
output should show up in the console.
* Pipelines:
PipelineConnectionBase finally has a functional fault handling
mechanism. Issues remain here but they are fundamentally difficult
problems due to the nature of pipelining commands and the best way to
address these is not yet clear to me. As of now, we have a series of
commands have been sent to Redis on queueRequest(..) and at some point
(while requests are ongoing) the resonse handler detects connection
fault. Clearly the current pending response being handled is in error
(i.e. res.get() will throw an ExecutionException per Future's
semantics, and the cause will be a flavor of ClientRuntimeException
spelling out the problem). And as of now, the remaining pending
responses are all also set to an excepted state.
But there is no mechanism in place to determine which subset of WRITE
commands actually made it to Redis. This is partly due to the nature
of pipelining, and also due to the fact that writes to broken pipes
(sockets) in Java do NOT throw exceptions, so you really don't know a
connection is broken until you read, so there is no way for the
pipeline to know which subset of its sends actually made it to
redis.
So ambiguities remain in that regard. But if you are queuing your
future responses, then you will have the opportunity to walk your
pending q and check to see which of the requests are in an excepted
state. The associated cmd is accessible and that may help in taking
error recovery actions at the application level.
* AsynchConnection
Is a problem child. It refuses to throw exceptions when the redis
server is taken down and instead keeps going until it exhausts JVM
heap. Not sure what the issue is yet, and that is a TODO. [Q: does
anyone even use this connection and the associated JRedisAsynchClient?
If not, we can just chuck it. ;)
commits range:
begin: http://github.com/alphazero/jredis/commit/4d6b2fbef5d4ec3d54a02fca8fd6c6ea04892220
end: http://github.com/alphazero/jredis/commit/a3d992ddd0477a9443675afdc45b14000d5ed50c