Race condition reading objects

Rusty Klophaus rusty at basho.com
Tue Nov 1 08:36:59 EDT 2011


Hi Elias,

Whew, that is some top-shelf debugging. Glad to hear you were able to track
down the issue.

Best,
Rusty

On Tue, Nov 1, 2011 at 1:49 AM, Elias Levy <fearsome.lucidity at gmail.com>wrote:

> 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.
>
>


-- 
Rusty Klophaus (@rustyio)
*Basho Technologies, Inc.*
www.basho.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.basho.com/pipermail/riak-users_lists.basho.com/attachments/20111101/d6c6aa01/attachment.html>


More information about the riak-users mailing list