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.lucid...@gmail.com>wrote: > On Mon, Oct 31, 2011 at 11:14 PM, Elias Levy > <fearsome.lucid...@gmail.com>wrote: > >> On Mon, Oct 31, 2011 at 2:01 PM, Rusty Klophaus <ru...@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
_______________________________________________ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
