Race condition reading objects
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the riak-users