Race condition reading objects
rusty at basho.com
Tue Nov 1 08:36:59 EDT 2011
Whew, that is some top-shelf debugging. Glad to hear you were able to track
down the issue.
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
Rusty Klophaus (@rustyio)
*Basho Technologies, Inc.*
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the riak-users