I can test with large string quickly. In the test app I may be sending fewer bytes, but in my real app I am sending way more bytes.
FYI: I started with SASL auth, which was failing intermittently. After debugging I realized something is not right with binary protocol, then I disabled the SASL to take it our of picture completely, and spawned the memcached with binary protocol and still I see the the intermittent behavior. On Wednesday, April 26, 2017 at 9:54:00 PM UTC-7, Dormando wrote: > > Looks like the protocol is getting out of sync somehow. > > conn_waiting only means it's waiting to read more bytes from the socket > from a set. Then it looks like the client doesn't send anymore bytes, > times out, then closes the socket (-> conn_read -> conn_closing). > > It's most likely a bug in how you're using the binary protocol, but it's > hard to say from here. Somehow you're writing fewer bytes to the socket > than you told the binary protocol to receive. > > On Wed, 26 Apr 2017, watul123 wrote: > > > Yes I am 100% sure. > > When the binary protocol is in picture then only this happens, otherwise > same test program with same argument runs perfect. I debugged a lot before > > posting to this group. I am with you on the fact the binary protocol has > nothing to do with the timeouts, but it is the one cause the failure while > > reading from socket, then I guess the connection gets close, and at the > application level I get MEMCACHED_TIMEOUT. > > > > This is what I see on memcached's log > > > > 36: going from conn_parse_cmd to conn_mwrite > > 36: going from conn_mwrite to conn_new_cmd > > 36: going from conn_new_cmd to conn_waiting > > 36: going from conn_waiting to conn_read > > 36: going from conn_read to conn_closing > > <36 connection closed. > > 36: going from conn_closing to conn_closed > > > > > > > > On Wednesday, April 26, 2017 at 5:02:04 PM UTC-7, Dormando wrote: > > Any way to get more information about the timeouts you're seeing? > > > > There's nothing in the protocol that would cause "timeouts", but > bugs > > somewhere could cause clients to hang waiting on more data I > guess. > > > > You're sure they're timeouts and not some other kind of error? > > > > On Wed, 26 Apr 2017, Atul Waghmare wrote: > > > > > Hi there, > > > > > > I am facing one issue with memcached binary protocol. Whenever I > force the memcached to use the binary protocol, my application get > > occasional timeouts > > > and occasional success. The percentage of failure(set timeouts) > is more than 80% when the memcached spawn with binary protocol . The moment > > I remove the > > > binary option, the success rate is 100%. > > > > > > memcached - v1.4.36 > > > libmemcached -v1.0.18 > > > > > > Any idea what may be wrong? > > > > > > Thanks, > > > Atul > > > > > > -- > > > > > > --- > > > 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 memcached+...@googlegroups.com. > > > For more options, visit https://groups.google.com/d/optout. > > > > > > > > > > -- > > > > --- > > 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 memcached+...@googlegroups.com <javascript:>. > > For more options, visit https://groups.google.com/d/optout. > > > > -- --- 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 memcached+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
