error on timeout now handled by jackpot #136
Conversation
|
Hmm, I don't think this is quite right actually, I'll follow up... |
|
Working on some changes with this. It seems overall that Jackpot should, and does, handle any pre 'connect' errors, and treats a timeout while trying to connect as an error, and that node-memcached should handle any post 'connect' errors by reporting them to connectionIssue(). |
|
I updated the pull. The idea is that Jackpot handled pre-connect timeouts and errors, while, node-memcached needs to listen for any errors on the socket post-connect. |
|
Looks really slick, thanks for the work on this. Do you think it makes sense to move the removal/releasing of the connections in to Jackpot instead of adding logic against it in memcached? |
error on timeout now handled by jackpot
|
@3rd-Eden thanks. Yes, I think it could make sense. Something related I've been thinking about is the ability to differentiate which errors should be considered "fatal" errors, and which errors should just be considered warnings, whereby only "fatal" errors would put nodes into a failed state. For example, if you try to SET an item larger than the allowed size, node-memcached emits an error, which may not be considered "fatal" / worth marking a node failed. Have you thought about working this into the issue logging system? Will issue logging live in failover in 1.0? |
Fixes broken tests in #135 ... now that Jackpot returns error on timeout when trying to connect socket, node-memcached no longer needs to do so.