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.
_______________________________________________ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
