Hi guys, Good news: everything's working now, here, with your help I figured out how to deal with this situation; However, I opted by forcing the ordering of the requests and responses in my proxy, because of the specific needs for the proxy. (I could explain in details, but I thought it would be just noise in the discussion.)
Brian, I've tried to set that behavior to different values (0, 1, 100 and 1000), and they all behave the same: I first get a response from Memcached, for the first key, before sending the no-op request. (In other words, the same behavior as I noticed in the beginning.) I've done this by setting the "_io_key_prefetch" behavior in pylibmc, which should map to MEMCACHED_BEHAVIOR_IO_KEY_PREFETCH. (If you try with "io_key_prefetch", without the initial underscore, it breaks.) Thanks a lot for the help, guys! You're amazing! :-) Cheers! __________________________ Diogo Baeder http://diogobaeder.com.br On Tue, Feb 19, 2013 at 8:00 PM, Brian Aker <[email protected]> wrote: > Agreed, I'll take a look and see why that is happening. > > From looking at the code I can see where it is happening, I just need to > find out if there was a reason for it. The default value for > io_key_prefetch is zero, which is what is causing the flush to happen: > > > http://docs.libmemcached.org/memcached_behavior.html?highlight=memcached_behavior_io_key_prefetch#MEMCACHED_BEHAVIOR_IO_KEY_PREFETCH > > It would be interesting to see what would happen if the original reporter > of this issue modified that value upward. > > Cheers, > -Brian > > On Feb 19, 2013, at 12:28 PM, dormando <[email protected]> wrote: > > > > > > > On Tue, 19 Feb 2013, Trond Norbye wrote: > > > >> Its been a while since I looked at that code but if my memory is > correct we're using the "quiet' mode of the get requests so that it won't > send "not found" results. The noop is then used as an internal marker so > that you know on the receiving side that you've > >> received all of the responses from the server.. > >> But I might remember this wrong.. after all its been a few years since > I last looked at the code. > >> > >> Trond > >> > >> > >> > >> On Tue, Feb 19, 2013 at 5:07 PM, Brian Aker <[email protected]> wrote: > >> Hi, > >> > >> On Feb 19, 2013, at 12:14 AM, dormando <[email protected]> wrote: > >> > >>> Both keys go out okay, but the no-op at the end seems to go out in a > >>> separate packet. I've noticed this on several installs using > libmemcached, > >>> verified with tcpdump/etc. > >> > >> I didn't write this part of the binary code, Trond did. I am not sure > why the NOOP is required. I would think that a simple flush of the buffer > would be fine. > >> > >> Cheers, > >> -Brian > >> > >> > >> > >> > >> -- > >> Trond Norbye > >> > >> -- > >> > >> --- > >> You received this message because you are subscribed to the Google > Groups "memcached" group. > >> To unsubscribe from this group and stop receiving emails from it, send > an email to [email protected]. > >> For more options, visit https://groups.google.com/groups/opt_out. > >> > >> > >> > >> > > > > -- > > --- > You received this message because you are subscribed to the Google Groups > "memcached" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- --- You received this message because you are subscribed to the Google Groups "memcached" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
