seancribbs/ripple — comment on commit e5f24a5d54cd1f8f3bac3354cbbbd0c71b8a8d6d
File:  line 0
By myronmarston:

FWIW, this is what I'm using to handle retries of these errors:

``` ruby

require 'excon'
require 'riak/client'

module Silo
module RiakClientRetryable
TRANSIENT_ERRORS = [ Riak::HTTPFailedRequest, Riak::MapReduceError ]

def perform(*args, &block)
dup_args = args.dup
super(*args, &block)
rescue *TRANSIENT_ERRORS
super(*dup_args, &block)
end
end
end

class << Riak::Client::ExconBackend
def new(*args)
super.tap do |instance|
instance.extend(Silo::RiakClientRetryable)
end
end
end
```

I wouldn't want or expect this to ever be in riak-client itself, but I do want to confirm that this won't cause any problems with the new connection pooling/retry logic since I have a very cursory understanding of it.

I think this won't cause problems with the stuff you mentions (connection teardown, node error rates, etc) because this is directly on the excon backend, and thus happens within a single checkout of the connection from the pool. If one of these errors happens once and we retry and it works, then great...we get a valid response. If one of these errors happens a second time, it bubbles up just like any other error. @aphyr: thoughts on this being OK and not conflicting with the new logic?