riakc_pb_socket uses {active, once} to receive TCP data as messages. In order to support timeouts on reading this data, it also sends itself messages using erlang:send_after. Since only one request can be outstanding at once, concurrent requests are queued up, and processed FIFO. However, the timer for an individual request is started when the request is queued, not when it is actually sent to Riak. The problem is that we start the timer (send_after) inside of new_request, when this request might just be queued. This has two consequences:
The timer may go off when we've been waiting on TCP data for less than timeout.
This may actually be on purpose, but to me it conflates a TCP read timeout with an 'overall request' timeout, which would include time spent waiting in the queue.
riakc_pb_socket
uses{active, once}
to receive TCP data as messages. In order to support timeouts on reading this data, it also sends itself messages usingerlang:send_after
. Since only one request can be outstanding at once, concurrent requests are queued up, and processed FIFO. However, the timer for an individual request is started when the request is queued, not when it is actually sent to Riak. The problem is that we start the timer (send_after) inside ofnew_request
, when this request might just be queued. This has two consequences:timeout
.This may actually be on purpose, but to me it conflates a TCP read timeout with an 'overall request' timeout, which would include time spent waiting in the queue.