Race condition reading objects

Elias Levy fearsome.lucidity at gmail.com
Tue Nov 1 01:49:12 EDT 2011


On Mon, Oct 31, 2011 at 11:14 PM, Elias Levy <fearsome.lucidity at gmail.com>wrote:

> On Mon, Oct 31, 2011 at 2:01 PM, Rusty Klophaus <rusty at basho.com> wrote:
>
>> Thanks for your excellent description of the problem. We haven't seen
>> this before to my knowledge, and this isn't expected behavior.
>> Also, if you can share your code, or if you have a small script that can
>> reproduce the failure, that would be extremely helpful.
>>
>
> I created a small test script that reliable reproduces the issue, but I
> created another version that creates truly independent clients (distinct
> processes) and I could not reproduce it.  So there issue must lie somewhere
> in my Fiber based client software stack.  Somewhere within em-synchrony or
> EventMachine some shared state must be getting clobbered at high processing
> rates, or the high rate is causing EventMachine to return a short read
> under some circumstances.
>

Figured it is a false implementation of read in em-synchrony's TCPSocket.
 It implements recv's behavior, returning partial results, instead of
read's behavior of waiting for enough data or an EOF.  Logged at
https://github.com/igrigorik/em-synchrony/issues/77.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.basho.com/pipermail/riak-users_lists.basho.com/attachments/20111031/b59cd1af/attachment.html>


More information about the riak-users mailing list