Ok.

The binary protocol is tested pretty well so it's *probably* something in
your program, but I won't rule out a bug on the server either. The binary
protocol is in heavy usage in a bunch of places though.

On Wed, 26 Apr 2017, watul123 wrote:

> 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.
>       > 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.
>
>

-- 

--- 
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.

Reply via email to