Haven't had a chance to get back to this.  I am not sure how critical it is
until later on in our optimization efforts (or naturally over time as there
are more cores).  The kill is just a best effort anyway, given disterl.  I
am OK with sending a dont_care message, although we get bit again by the
gen_fsm 'have I covered all the states' thing.

Will try to rework for next week.


On Fri, Dec 13, 2013 at 3:46 PM, Jon Meredith <notifications@github.com>wrote:

> In src/riak_client.erl:
>
> >      after Timeout ->
> > +            exit(Pid, kill),
>
> Brutally killing request process prevents actions like read repair taking
> place for any partial results and reporting any stats on timeouts (not that
> it does a great job right now, but it should).
>
> If there were mass timeouts around anything that uses a non-sidejob
> supervisor (for example deletion) could enough kills cause that supervisor
> to die and cause the application supervisor above to be unhappy enough to
> exit the app and take the node down?
>
> Sending a message would be nicer (a Phil Collins "I don't care any more"),
> but that only works for requests on the local node, anything overdisterl
> would have issues.
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/basho/riak_kv/pull/693/files#r8348746>
> .
>