Re: binary protocol?
maybe could be used something like flatbuffers? Em qui, 9 de mai de 2019 às 20:15, dormando escreveu: > To that end, I think SASL's confused everyone who's ever met it, and I > don't think anyone actually asked for it back in binprot days. > > Said I was going to do this before but hadn't... Lets try something > simple, and if someone asks for SASL I think it's actually easy: > > client connect: > set auth 0 0 [length] > username password > \r\n > > ... and if you get back a STORED, you're good to go. if you try to run any > other command you'll get: > > CLIENT_ERROR unauthorized > > password database is a username:password\n file on disk, reloaded when it > changes. no fancy datastructures so will get slow if people use a billion > users. user's don't do anything, but putting them there now in case we > ever decide to. > > if we ever decide to support SASL again: > > client connect: > get mech-list > MECH CRAM-MD5 PLAIN ETC > END > > set sasl-step 0 0 [length] > data > STORED > > get authenticated > [indicates done or STEP if SASL requires more steps] > > ... extra roundtrip in the protocol but this could be solved with > mget/mset. > > On Thu, 9 May 2019, dormando wrote: > > > Indeed we would. SASL is actually a text based protocol, as it's used in > > SMTP and similar. That shouldn't be too bad. > > > > On Thu, 9 May 2019, Om Kale wrote: > > > > > Hey Dormando,As of now only binary protocol supports SASL. > > > Correct me if I am wrong but to ensure compatibility with SASL and > libmemcached clients we would need binary protocol support right? > > > > > > > > > Thanks and Regards,Om Kale > > > > > > > > > > > > On Thu, May 9, 2019 at 2:58 PM dormando wrote: > > > Yo, > > > > > > Any of you out there really _like_ the binary protocol? Aside > from the > > > features it gives (CAS everywhere, pipelining, etc). > > > > > > just thinkin' through some things. > > > > > > Thanks, > > > -Dormando > > > > > > -- > > > > > > --- > > > 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. > > > To view this discussion on the web visit > https://groups.google.com/d/msgid/memcached/alpine.DEB.2.21.1905091457160.27082%40dskull > . > > > 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. > > > To view this discussion on the web visit > > > > https://groups.google.com/d/msgid/memcached/CANvBZ%3DvraaTi48Yu-a07gfc-OCAJ%3DfJfA_z97XA3UvjFretK5g%40mail.gmail.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. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/memcached/alpine.DEB.2.21.1905091527370.27082%40dskull > . > > 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. > To view this discussion on the web visit > https://groups.google.com/d/msgid/memcached/alpine.DEB.2.21.1905091608320.27082%40dskull > . > For more options, visit https://groups.google.com/d/optout. > -- Roberto Spadim -- --- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/memcached/CAH3kUhGq%2B5FpF8C4wDDPFijMwEka8Q4cKGu%2B43vOJqiB__P7_Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: binary protocol?
flatbuffers are unrelated to protocol, and are definitely not backwards compatible with ascii :p On Thu, 9 May 2019, Roberto Spadim wrote: > maybe could be used something like flatbuffers? > > Em qui, 9 de mai de 2019 às 20:15, dormando escreveu: > To that end, I think SASL's confused everyone who's ever met it, and I > don't think anyone actually asked for it back in binprot days. > > Said I was going to do this before but hadn't... Lets try something > simple, and if someone asks for SASL I think it's actually easy: > > client connect: > set auth 0 0 [length] > username password > \r\n > > ... and if you get back a STORED, you're good to go. if you try to run > any > other command you'll get: > > CLIENT_ERROR unauthorized > > password database is a username:password\n file on disk, reloaded when > it > changes. no fancy datastructures so will get slow if people use a > billion > users. user's don't do anything, but putting them there now in case we > ever decide to. > > if we ever decide to support SASL again: > > client connect: > get mech-list > MECH CRAM-MD5 PLAIN ETC > END > > set sasl-step 0 0 [length] > data > STORED > > get authenticated > [indicates done or STEP if SASL requires more steps] > > ... extra roundtrip in the protocol but this could be solved with > mget/mset. > > On Thu, 9 May 2019, dormando wrote: > > > Indeed we would. SASL is actually a text based protocol, as it's used > in > > SMTP and similar. That shouldn't be too bad. > > > > On Thu, 9 May 2019, Om Kale wrote: > > > > > Hey Dormando,As of now only binary protocol supports SASL. > > > Correct me if I am wrong but to ensure compatibility with SASL and > libmemcached clients we would need binary protocol support right? > > > > > > > > > Thanks and Regards,Om Kale > > > > > > > > > > > > On Thu, May 9, 2019 at 2:58 PM dormando wrote: > > > Yo, > > > > > > Any of you out there really _like_ the binary protocol? Aside > from the > > > features it gives (CAS everywhere, pipelining, etc). > > > > > > just thinkin' through some things. > > > > > > Thanks, > > > -Dormando > > > > > > -- > > > > > > --- > > > 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. > > > To view this discussion on the web visit > https://groups.google.com/d/msgid/memcached/alpine.DEB.2.21.1905091457160.27082%40dskull. > > > 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. > > > To view this discussion on the web visit > > > > https://groups.google.com/d/msgid/memcached/CANvBZ%3DvraaTi48Yu-a07gfc-OCAJ%3DfJfA_z97XA3UvjFretK5g%40mail.gmail.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. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/memcached/alpine.DEB.2.21.1905091527370.27082%40dskull. > > 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...@goo
Re: binary protocol?
To that end, I think SASL's confused everyone who's ever met it, and I don't think anyone actually asked for it back in binprot days. Said I was going to do this before but hadn't... Lets try something simple, and if someone asks for SASL I think it's actually easy: client connect: set auth 0 0 [length] username password \r\n ... and if you get back a STORED, you're good to go. if you try to run any other command you'll get: CLIENT_ERROR unauthorized password database is a username:password\n file on disk, reloaded when it changes. no fancy datastructures so will get slow if people use a billion users. user's don't do anything, but putting them there now in case we ever decide to. if we ever decide to support SASL again: client connect: get mech-list MECH CRAM-MD5 PLAIN ETC END set sasl-step 0 0 [length] data STORED get authenticated [indicates done or STEP if SASL requires more steps] ... extra roundtrip in the protocol but this could be solved with mget/mset. On Thu, 9 May 2019, dormando wrote: > Indeed we would. SASL is actually a text based protocol, as it's used in > SMTP and similar. That shouldn't be too bad. > > On Thu, 9 May 2019, Om Kale wrote: > > > Hey Dormando,As of now only binary protocol supports SASL. > > Correct me if I am wrong but to ensure compatibility with SASL and > > libmemcached clients we would need binary protocol support right? > > > > > > Thanks and Regards,Om Kale > > > > > > > > On Thu, May 9, 2019 at 2:58 PM dormando wrote: > > Yo, > > > > Any of you out there really _like_ the binary protocol? Aside from the > > features it gives (CAS everywhere, pipelining, etc). > > > > just thinkin' through some things. > > > > Thanks, > > -Dormando > > > > -- > > > > --- > > 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. > > To view this discussion on the web visit > > https://groups.google.com/d/msgid/memcached/alpine.DEB.2.21.1905091457160.27082%40dskull. > > 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. > > To view this discussion on the web visit > > https://groups.google.com/d/msgid/memcached/CANvBZ%3DvraaTi48Yu-a07gfc-OCAJ%3DfJfA_z97XA3UvjFretK5g%40mail.gmail.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. > To view this discussion on the web visit > https://groups.google.com/d/msgid/memcached/alpine.DEB.2.21.1905091527370.27082%40dskull. > 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. To view this discussion on the web visit https://groups.google.com/d/msgid/memcached/alpine.DEB.2.21.1905091608320.27082%40dskull. For more options, visit https://groups.google.com/d/optout.
Re: binary protocol?
Indeed we would. SASL is actually a text based protocol, as it's used in SMTP and similar. That shouldn't be too bad. On Thu, 9 May 2019, Om Kale wrote: > Hey Dormando,As of now only binary protocol supports SASL. > Correct me if I am wrong but to ensure compatibility with SASL and > libmemcached clients we would need binary protocol support right? > > > Thanks and Regards,Om Kale > > > > On Thu, May 9, 2019 at 2:58 PM dormando wrote: > Yo, > > Any of you out there really _like_ the binary protocol? Aside from the > features it gives (CAS everywhere, pipelining, etc). > > just thinkin' through some things. > > Thanks, > -Dormando > > -- > > --- > 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. > To view this discussion on the web visit > https://groups.google.com/d/msgid/memcached/alpine.DEB.2.21.1905091457160.27082%40dskull. > 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. > To view this discussion on the web visit > https://groups.google.com/d/msgid/memcached/CANvBZ%3DvraaTi48Yu-a07gfc-OCAJ%3DfJfA_z97XA3UvjFretK5g%40mail.gmail.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. To view this discussion on the web visit https://groups.google.com/d/msgid/memcached/alpine.DEB.2.21.1905091527370.27082%40dskull. For more options, visit https://groups.google.com/d/optout.
Re: binary protocol?
Hey Dormando, As of now only binary protocol supports SASL. Correct me if I am wrong but to ensure compatibility with SASL and libmemcached clients we would need binary protocol support right? Thanks and Regards, Om Kale On Thu, May 9, 2019 at 2:58 PM dormando wrote: > Yo, > > Any of you out there really _like_ the binary protocol? Aside from the > features it gives (CAS everywhere, pipelining, etc). > > just thinkin' through some things. > > Thanks, > -Dormando > > -- > > --- > 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. > To view this discussion on the web visit > https://groups.google.com/d/msgid/memcached/alpine.DEB.2.21.1905091457160.27082%40dskull > . > 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. To view this discussion on the web visit https://groups.google.com/d/msgid/memcached/CANvBZ%3DvraaTi48Yu-a07gfc-OCAJ%3DfJfA_z97XA3UvjFretK5g%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
binary protocol?
Yo, Any of you out there really _like_ the binary protocol? Aside from the features it gives (CAS everywhere, pipelining, etc). just thinkin' through some things. Thanks, -Dormando -- --- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/memcached/alpine.DEB.2.21.1905091457160.27082%40dskull. For more options, visit https://groups.google.com/d/optout.
Re: Memcached Binary protocol
I don't think its SASL, if I am following the memcached logs correctly then its failing while doing a read from FD(it gets zero bytes which results in READ_ERROR). Look at the following back to back fail and success. Read fails well before the SASL(auth and etc) comes into picture, *but surprisingly it fails only when SASL is enabled.* Interesting thing is, I tried the same thing on 5 different machines(RHEL6/5 VM), among which it works perfect on two machine(this is very confusing for me) and fails on 3 machines(VM). At tcp level I don't see any difference in the working and non working machines. Is there any tuning( at system level) which may needs to be done to make this Memcache-SASL combination to work? Just to go further, I was monitoring the FD's of the process memcached (under /proc/memcache_pid/fd), the thing I observed is whenever my app gets the MEMCACHED_TIMEOUT there are two new fds, and whenever my app gets "Success" there is only one new FD (36 in my case), like below. (Note:- I tried with db handle open option and in that case I see one FD points to db, but still in every failure I see two new FDs apart from the db handle fd, and in case of success only one new FD which is 36) *lrwx-- 1 root root 64 May 2 15:39 37 -> socket:[39863]lrwx-- 1 root root 64 May 2 15:39 36 -> socket:[39861]* *Memcached Logs*<36 new binary client connection. 36: going from conn_new_cmd to conn_waiting 36: going from conn_waiting to conn_read 36: going from conn_read to conn_parse_cmd <36 Read binary protocol data: <360x80 0x20 0x00 0x00 <360x00 0x00 0x00 0x00 <360x00 0x00 0x00 0x00 <360x00 0x02 0x00 0x00 <360x00 0x00 0x00 0x00 <360x00 0x00 0x00 0x00 authenticated() in cmd 0x20 is true >36 Writing bin response: >36 0x81 0x20 0x00 0x00 >36 0x00 0x00 0x00 0x00 >36 0x00 0x00 0x00 0x05 >36 0x00 0x02 0x00 0x00 >36 0x00 0x00 0x00 0x00 >36 0x00 0x00 0x00 0x00 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_parse_cmd <36 Read binary protocol data: <360x80 0x21 0x00 0x05 <360x00 0x00 0x00 0x00 <360x00 0x00 0x00 0x16 <360x00 0x02 0x00 0x00 <360x00 0x00 0x00 0x00 <360x00 0x00 0x00 0x00 authenticated() in cmd 0x21 is true 36: going from conn_parse_cmd to conn_nread mech: ``PLAIN'' with 17 bytes of data sasl result code: 0 >36 Writing bin response: >36 0x81 0x21 0x00 0x00 >36 0x00 0x00 0x00 0x00 >36 0x00 0x00 0x00 0x0d >36 0x00 0x02 0x00 0x00 >36 0x00 0x00 0x00 0x00 >36 0x00 0x00 0x00 0x00 36: going from conn_nread 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_parse_cmd <36 Read binary protocol data: <360x80 0x01 0x00 0x4d <360x08 0x00 0x00 0x00 <360x00 0x00 0x00 0xa1 <360x00 0x01 0x00 0x00 <360x00 0x00 0x00 0x00 <360x00 0x00 0x00 0x00 authenticated() in cmd 0x01 is true 36: going from conn_parse_cmd to conn_nread <36 SET abcdefghij999 Value len is 76 > FOUND KEY abcdefghij999 >36 Writing bin response: >36 0x81 0x01 0x00 0x00 >36 0x00 0x00 0x00 0x00 >36 0x00 0x00 0x00 0x00 >36 0x00 0x01 0x00 0x00 >36 0x00 0x00 0x00 0x00 >36 0x00 0x00 0x00 0x04 36: going from conn_nread 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_parse_cmd <36 Read binary protocol data: <360x80 0x0c 0x00 0x4d <360x00 0x00 0x00 0x00 <360x00 0x00 0x00 0x4d <360x00 0x03 0x00 0x00 <360x00 0x00 0x00 0x00 <360x00 0x00 0x00 0x00 authenticated() in cmd 0x0c is true 36: going from conn_parse_cmd to conn_nread <36 GET abcdefghij999 > FOUND KEY abcdefghij999 >36 Writing bin response: >36 0x81 0x0c 0x00 0x4d >36 0x04 0x00 0x00 0x00 >36 0x00 0x00 0x00 0x9d >36 0x00 0x03 0x00 0x00 >36 0x00 0x00 0x00 0x00 >36 0x00 0x00 0x00 0x00 36: going from conn_nread 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_parse_cmd <36 Read binary protocol data: <360x80 0x07 0x00 0x00 <360x00 0x00 0x00 0x00 <360x00 0x00 0x00 0x00 <360x00 0x04 0x00 0x00 <360x00 0x00 0x00 0x00 <360x
Re: Memcached Binary protocol
Sounds like the underlying SASL service is failing sometimes? I don't think there's anything in the memcached code that would cause this. On Sat, 29 Apr 2017, watul123 wrote: > I am using same connection once the connection is established. What I see so > far is the inconsistency in the establishing the connection itself. As > pasted above in the logs, for same password/user name, same setup, same test > program, same memcached bin, if I run the test program multiple times from > command line, memcached_set either returns success or the > timeout(MEMCACHED_TIMEOUT). The logs from the server side shows.. > > going from conn_read to conn_closing > <36 connection closed. > 36: going from conn_closing to conn_closed > > If the connection establishment is successful then I can set/get "n" number > of values without any issue. > > > On Wednesday, April 26, 2017 at 11:57:43 PM UTC-7, Dormando wrote: > Are you reusing connections, or re-SASL'ing every time? I wonder if the > underlying sasl daemon/mechanism is failing. SASL stuff is only ever > checked when the connection is first established. All requests after the > connection setup is fine. > > On Wed, 26 Apr 2017, watul123 wrote: > > > I think the binary protocol just works as expected, there is nothing > to do with length as well, it was my test program where I commented > out the below > > line > > "memcached_behavior_set(cache, MEMCACHED_BEHAVIOR_BINARY_PROTOCOL, > 1);" > > > > After fixing(un commenting) this line, no matter what length the > key/value are , it's success all the time. > > > > The actual issue is with SASL- connection gets closed all of sudden > like below, and the app gets Set Timeout, where as same thing gives > success some time > > Failed > > <36 new binary client connection. > > 36: going from conn_new_cmd to conn_waiting > > 36: going from conn_waiting to conn_read > > 36: going from conn_read to conn_parse_cmd > > <36 Read binary protocol data: > > <36 0x80 0x20 0x00 0x00 > > <36 0x00 0x00 0x00 0x00 > > <36 0x00 0x00 0x00 0x00 > > <36 0x00 0x02 0x00 0x00 > > <36 0x00 0x00 0x00 0x00 > > <36 0x00 0x00 0x00 0x00 > > authenticated() in cmd 0x20 is true > > >36 Writing bin response: > > >36 0x81 0x20 0x00 0x00 > > >36 0x00 0x00 0x00 0x00 > > >36 0x00 0x00 0x00 0x05 > > >36 0x00 0x02 0x00 0x00 > > >36 0x00 0x00 0x00 0x00 > > >36 0x00 0x00 0x00 0x00 > > 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. > > > > Success: > > <36 new binary client connection. > > 36: going from conn_new_cmd to conn_waiting > > 36: going from conn_waiting to conn_read > > 36: going from conn_read to conn_parse_cmd > > <36 Read binary protocol data: > > <36 0x80 0x20 0x00 0x00 > > <36 0x00 0x00 0x00 0x00 > > <36 0x00 0x00 0x00 0x00 > > <36 0x00 0x02 0x00 0x00 > > <36 0x00 0x00 0x00 0x00 > > <36 0x00 0x00 0x00 0x00 > > authenticated() in cmd 0x20 is true > > >36 Writing bin response: > > >36 0x81 0x20 0x00 0x00 > > >36 0x00 0x00 0x00 0x00 > > >36 0x00 0x00 0x00 0x05 > > >36 0x00 0x02 0x00 0x00 > > >36 0x00 0x00 0x00 0x00 > > >36 0x00 0x00 0x00 0x00 > > 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_parse_cmd > > <36 Read binary protocol data: > > <36 0x80 0x21 0x00 0x05 > > <36 0x00 0x00 0x00 0x00 > > <36 0x00 0x00 0x00 0x16 > > <36 0x00 0x02 0x00 0x00 > > <36 0x00 0x00 0x00 0x00 > > <36 0x00 0x00 0x00 0x00 > > authenticated() in cmd 0x21 is true > > 36: going from conn_parse_cmd to conn_nread > > mech:
Re: Memcached Binary protocol
I am using same connection once the connection is established. What I see so far is the inconsistency in the establishing the connection itself. As pasted above in the logs, for same password/user name, same setup, same test program, same memcached bin, if I run the test program multiple times from command line, memcached_set either returns success or the timeout(MEMCACHED_TIMEOUT). The logs from the server side shows.. going from conn_read to conn_closing <36 connection closed. 36: going from conn_closing to conn_closed If the connection establishment is successful then I can set/get "n" number of values without any issue. On Wednesday, April 26, 2017 at 11:57:43 PM UTC-7, Dormando wrote: > > Are you reusing connections, or re-SASL'ing every time? I wonder if the > underlying sasl daemon/mechanism is failing. SASL stuff is only ever > checked when the connection is first established. All requests after the > connection setup is fine. > > On Wed, 26 Apr 2017, watul123 wrote: > > > I think the binary protocol just works as expected, there is nothing to > do with length as well, it was my test program where I commented out the > below > > line > > "memcached_behavior_set(cache, MEMCACHED_BEHAVIOR_BINARY_PROTOCOL, 1);" > > > > After fixing(un commenting) this line, no matter what length the > key/value are , it's success all the time. > > > > The actual issue is with SASL- connection gets closed all of sudden like > below, and the app gets Set Timeout, where as same thing gives success some > time > > Failed > > <36 new binary client connection. > > 36: going from conn_new_cmd to conn_waiting > > 36: going from conn_waiting to conn_read > > 36: going from conn_read to conn_parse_cmd > > <36 Read binary protocol data: > > <360x80 0x20 0x00 0x00 > > <360x00 0x00 0x00 0x00 > > <360x00 0x00 0x00 0x00 > > <360x00 0x02 0x00 0x00 > > <360x00 0x00 0x00 0x00 > > <360x00 0x00 0x00 0x00 > > authenticated() in cmd 0x20 is true > > >36 Writing bin response: > > >36 0x81 0x20 0x00 0x00 > > >36 0x00 0x00 0x00 0x00 > > >36 0x00 0x00 0x00 0x05 > > >36 0x00 0x02 0x00 0x00 > > >36 0x00 0x00 0x00 0x00 > > >36 0x00 0x00 0x00 0x00 > > 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. > > > > Success: > > <36 new binary client connection. > > 36: going from conn_new_cmd to conn_waiting > > 36: going from conn_waiting to conn_read > > 36: going from conn_read to conn_parse_cmd > > <36 Read binary protocol data: > > <360x80 0x20 0x00 0x00 > > <360x00 0x00 0x00 0x00 > > <360x00 0x00 0x00 0x00 > > <360x00 0x02 0x00 0x00 > > <360x00 0x00 0x00 0x00 > > <360x00 0x00 0x00 0x00 > > authenticated() in cmd 0x20 is true > > >36 Writing bin response: > > >36 0x81 0x20 0x00 0x00 > > >36 0x00 0x00 0x00 0x00 > > >36 0x00 0x00 0x00 0x05 > > >36 0x00 0x02 0x00 0x00 > > >36 0x00 0x00 0x00 0x00 > > >36 0x00 0x00 0x00 0x00 > > 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_parse_cmd > > <36 Read binary protocol data: > > <360x80 0x21 0x00 0x05 > > <360x00 0x00 0x00 0x00 > > <360x00 0x00 0x00 0x16 > > <360x00 0x02 0x00 0x00 > > <360x00 0x00 0x00 0x00 > > <360x00 0x00 0x00 0x00 > > authenticated() in cmd 0x21 is true > > 36: going from conn_parse_cmd to conn_nread > > mech: ``PLAIN'' with 17 bytes of data > > INFO: User <real@awpcabm02> failed to authenticate > > sasl result code: 0 > > >36 Writing bin response: > > >36 0x81 0x21 0x00 0x00 > > >36 0x00 0x00 0x00 0x00 > > >36 0x00 0x00 0x00 0x0d > > >36 0x00 0x02 0x00 0x00 > > >36 0x00 0x00 0x00 0x00 > > >36 0x00 0x00 0x00 0x00 > > 36: going from conn_nread 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 > > 3
Re: Memcached Binary protocol
Are you reusing connections, or re-SASL'ing every time? I wonder if the underlying sasl daemon/mechanism is failing. SASL stuff is only ever checked when the connection is first established. All requests after the connection setup is fine. On Wed, 26 Apr 2017, watul123 wrote: > I think the binary protocol just works as expected, there is nothing to do > with length as well, it was my test program where I commented out the below > line > "memcached_behavior_set(cache, MEMCACHED_BEHAVIOR_BINARY_PROTOCOL, 1);" > > After fixing(un commenting) this line, no matter what length the key/value > are , it's success all the time. > > The actual issue is with SASL- connection gets closed all of sudden like > below, and the app gets Set Timeout, where as same thing gives success some > time > Failed > <36 new binary client connection. > 36: going from conn_new_cmd to conn_waiting > 36: going from conn_waiting to conn_read > 36: going from conn_read to conn_parse_cmd > <36 Read binary protocol data: > <36 0x80 0x20 0x00 0x00 > <36 0x00 0x00 0x00 0x00 > <36 0x00 0x00 0x00 0x00 > <36 0x00 0x02 0x00 0x00 > <36 0x00 0x00 0x00 0x00 > <36 0x00 0x00 0x00 0x00 > authenticated() in cmd 0x20 is true > >36 Writing bin response: > >36 0x81 0x20 0x00 0x00 > >36 0x00 0x00 0x00 0x00 > >36 0x00 0x00 0x00 0x05 > >36 0x00 0x02 0x00 0x00 > >36 0x00 0x00 0x00 0x00 > >36 0x00 0x00 0x00 0x00 > 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. > > Success: > <36 new binary client connection. > 36: going from conn_new_cmd to conn_waiting > 36: going from conn_waiting to conn_read > 36: going from conn_read to conn_parse_cmd > <36 Read binary protocol data: > <36 0x80 0x20 0x00 0x00 > <36 0x00 0x00 0x00 0x00 > <36 0x00 0x00 0x00 0x00 > <36 0x00 0x02 0x00 0x00 > <36 0x00 0x00 0x00 0x00 > <36 0x00 0x00 0x00 0x00 > authenticated() in cmd 0x20 is true > >36 Writing bin response: > >36 0x81 0x20 0x00 0x00 > >36 0x00 0x00 0x00 0x00 > >36 0x00 0x00 0x00 0x05 > >36 0x00 0x02 0x00 0x00 > >36 0x00 0x00 0x00 0x00 > >36 0x00 0x00 0x00 0x00 > 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_parse_cmd > <36 Read binary protocol data: > <36 0x80 0x21 0x00 0x05 > <36 0x00 0x00 0x00 0x00 > <36 0x00 0x00 0x00 0x16 > <36 0x00 0x02 0x00 0x00 > <36 0x00 0x00 0x00 0x00 > <36 0x00 0x00 0x00 0x00 > authenticated() in cmd 0x21 is true > 36: going from conn_parse_cmd to conn_nread > mech: ``PLAIN'' with 17 bytes of data > INFO: User <real@awpcabm02> failed to authenticate > sasl result code: 0 > >36 Writing bin response: > >36 0x81 0x21 0x00 0x00 > >36 0x00 0x00 0x00 0x00 > >36 0x00 0x00 0x00 0x0d > >36 0x00 0x02 0x00 0x00 > >36 0x00 0x00 0x00 0x00 > >36 0x00 0x00 0x00 0x00 > 36: going from conn_nread 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_parse_cmd > <36 Read binary protocol data: > <36 0x80 0x01 0x00 0x17 > <36 0x08 0x00 0x00 0x00 > <36 0x00 0x00 0x00 0x39 > <36 0x00 0x01 0x00 0x00 > <36 0x00 0x00 0x00 0x00 > <36 0x00 0x00 0x00 0x00 > authenticated() in cmd 0x01 is true > 36: going from conn_parse_cmd to conn_nread > <36 SET abcefghjklmnopqrstvwxyz Value len is 26 > > NOT FOUND abcefghjklmnopqrstvwxyz > >36 Writing bin response: > >36 0x81 0x01 0x00 0x00 > >36 0x00 0x00 0x00 0x00 > >36 0x00 0x00 0x00 0x00 > >36 0x00 0x01 0x00 0x00 > >36 0x00 0x00 0x00 0x00 > >36 0x00 0x00 0x00 0x01 > 36: going from conn_nread 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_parse_cmd > <36 Read binary protocol data: > <36 0x80 0x0c 0x00 0x17 > <36 0x00 0x00 0x00 0x00 > <36 0x00 0x00 0x00 0x17 > <36 0x00 0x03 0x00 0x00 > <36 0x00 0x00 0x00 0x00 > <36 0x00 0x00 0x00 0x00 > authenticated() in cmd 0x0c is true > 36: going from conn_parse_cmd to
Re: Memcached Binary protocol
I think the binary protocol just works as expected, there is nothing to do with length as well, it was my test program where I commented out the below line "memcached_behavior_set(cache, MEMCACHED_BEHAVIOR_BINARY_PROTOCOL, 1);" After fixing(un commenting) this line, no matter what length the key/value are , it's success all the time. *The actual issue is with SASL*- connection gets closed all of sudden like below, and the app gets Set Timeout, where as same thing gives success some time *Failed*<36 new binary client connection. 36: going from conn_new_cmd to conn_waiting 36: going from conn_waiting to conn_read 36: going from conn_read to conn_parse_cmd <36 Read binary protocol data: <360x80 0x20 0x00 0x00 <360x00 0x00 0x00 0x00 <360x00 0x00 0x00 0x00 <360x00 0x02 0x00 0x00 <360x00 0x00 0x00 0x00 <360x00 0x00 0x00 0x00 authenticated() in cmd 0x20 is true >36 Writing bin response: >36 0x81 0x20 0x00 0x00 >36 0x00 0x00 0x00 0x00 >36 0x00 0x00 0x00 0x05 >36 0x00 0x02 0x00 0x00 >36 0x00 0x00 0x00 0x00 >36 0x00 0x00 0x00 0x00 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. *Success:*<36 new binary client connection. 36: going from conn_new_cmd to conn_waiting 36: going from conn_waiting to conn_read 36: going from conn_read to conn_parse_cmd <36 Read binary protocol data: <360x80 0x20 0x00 0x00 <360x00 0x00 0x00 0x00 <360x00 0x00 0x00 0x00 <360x00 0x02 0x00 0x00 <360x00 0x00 0x00 0x00 <360x00 0x00 0x00 0x00 authenticated() in cmd 0x20 is true >36 Writing bin response: >36 0x81 0x20 0x00 0x00 >36 0x00 0x00 0x00 0x00 >36 0x00 0x00 0x00 0x05 >36 0x00 0x02 0x00 0x00 >36 0x00 0x00 0x00 0x00 >36 0x00 0x00 0x00 0x00 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_parse_cmd <36 Read binary protocol data: <360x80 0x21 0x00 0x05 <360x00 0x00 0x00 0x00 <360x00 0x00 0x00 0x16 <360x00 0x02 0x00 0x00 <360x00 0x00 0x00 0x00 <360x00 0x00 0x00 0x00 authenticated() in cmd 0x21 is true 36: going from conn_parse_cmd to conn_nread mech: ``PLAIN'' with 17 bytes of data INFO: User <real@awpcabm02> failed to authenticate sasl result code: 0 >36 Writing bin response: >36 0x81 0x21 0x00 0x00 >36 0x00 0x00 0x00 0x00 >36 0x00 0x00 0x00 0x0d >36 0x00 0x02 0x00 0x00 >36 0x00 0x00 0x00 0x00 >36 0x00 0x00 0x00 0x00 36: going from conn_nread 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_parse_cmd <36 Read binary protocol data: <360x80 0x01 0x00 0x17 <360x08 0x00 0x00 0x00 <360x00 0x00 0x00 0x39 <360x00 0x01 0x00 0x00 <360x00 0x00 0x00 0x00 <360x00 0x00 0x00 0x00 authenticated() in cmd 0x01 is true 36: going from conn_parse_cmd to conn_nread <36 SET abcefghjklmnopqrstvwxyz Value len is 26 > NOT FOUND abcefghjklmnopqrstvwxyz >36 Writing bin response: >36 0x81 0x01 0x00 0x00 >36 0x00 0x00 0x00 0x00 >36 0x00 0x00 0x00 0x00 >36 0x00 0x01 0x00 0x00 >36 0x00 0x00 0x00 0x00 >36 0x00 0x00 0x00 0x01 36: going from conn_nread 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_parse_cmd <36 Read binary protocol data: <360x80 0x0c 0x00 0x17 <360x00 0x00 0x00 0x00 <360x00 0x00 0x00 0x17 <360x00 0x03 0x00 0x00 <360x00 0x00 0x00 0x00 <360x00 0x00 0x00 0x00 authenticated() in cmd 0x0c is true 36: going from conn_parse_cmd to conn_nread <36 GET abcefghjklmnopqrstvwxyz > FOUND KEY abcefghjklmnopqrstvwxyz >36 Writing bin response: >36 0x81 0x0c 0x00 0x17 >36 0x04 0x00 0x00 0x00 >36 0x00 0x00 0x00 0x35 >36 0x00 0x03 0x00 0x00 >36 0x00 0x00 0x00 0x00 >36 0x00 0x00 0x00 0x00 36: going from conn_nread 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_parse_cmd <36 Read binary protocol data: <360x80 0x07 0x00 0x00 <360x00 0x00 0x00 0x00 <360x00 0x00 0x00 0x00 <360x00 0x04 0x00 0x00 <360x00 0x00 0x00 0x00 <360x00 0x00 0x00 0x00 authenticated() in cmd 0x07 is true >36 Writing bin response: >36 0x81 0x07 0x00 0x00 >36 0x00 0x00 0x00 0x00 >36 0x00 0x00 0x00
Re: Memcached Binary protocol
Never mind, while debugging I commented out some lines and forgot to un-comment those. After fixing it, I don't see the bad magic issue. Importantly, the increase in the length of key:value in test program returns the success. So the inconsistency of binary protocol is no issue anymore, now I need to move to SASL again. *Dormando, thank you so much for your help, really appreciate it. * Thanks again, Atul On Wednesday, April 26, 2017 at 10:55:25 PM UTC-7, watul123 wrote: > > No, its just like below > > const char* key = "abczadfg"; > const char* value = "valuetestapp"; > > and > > I am using the this to ste the value "rc = memcached_set(cache, key, > strlen(key), value, strlen(value), (time_t)0, flags);" > > Thanks, > Atul > > On Wednesday, April 26, 2017 at 10:50:33 PM UTC-7, Dormando wrote: >> >> Your key isn't over 256 bytes is it? >> >> On Wed, 26 Apr 2017, watul123 wrote: >> >> > Ok, thanks. Let me debug in that direction. I will update the thread >> with my findings. >> > >> > BTW, if I increase the length of key and value in my test program with >> binary protocol then I consistently get CONNECTION FAILURE with below >> output on >> > memcached side >> > <36 new binary client connection. >> > 36: going from conn_new_cmd to conn_waiting >> > 36: going from conn_waiting to conn_read >> > 36: going from conn_read to conn_parse_cmd >> > <36 Read binary protocol data: >> > <360x73 0x65 0x74 0x20 >> > <360x61 0x62 0x63 0x7a >> > <360x20 0x30 0x20 0x30 >> > <360x20 0x36 0x0d 0x0a >> > <360x76 0x61 0x6c 0x75 >> > <36 0x65 0x65 0x0d 0x0a >> > Invalid magic: 73 >> > 36: going from conn_parse_cmd to conn_closing >> > <36 connection closed. >> > >> > Thanks again, >> > Atul >> > >> > On Wednesday, April 26, 2017 at 10:30:14 PM UTC-7, Dormando wrote: >> > 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_TI
Re: Memcached Binary protocol
No, its just like below const char* key = "abczadfg"; const char* value = "valuetestapp"; and I am using the this to ste the value "rc = memcached_set(cache, key, strlen(key), value, strlen(value), (time_t)0, flags);" Thanks, Atul On Wednesday, April 26, 2017 at 10:50:33 PM UTC-7, Dormando wrote: > > Your key isn't over 256 bytes is it? > > On Wed, 26 Apr 2017, watul123 wrote: > > > Ok, thanks. Let me debug in that direction. I will update the thread > with my findings. > > > > BTW, if I increase the length of key and value in my test program with > binary protocol then I consistently get CONNECTION FAILURE with below > output on > > memcached side > > <36 new binary client connection. > > 36: going from conn_new_cmd to conn_waiting > > 36: going from conn_waiting to conn_read > > 36: going from conn_read to conn_parse_cmd > > <36 Read binary protocol data: > > <360x73 0x65 0x74 0x20 > > <360x61 0x62 0x63 0x7a > > <360x20 0x30 0x20 0x30 > > <360x20 0x36 0x0d 0x0a > > <360x76 0x61 0x6c 0x75 > > <360x65 0x65 0x0d 0x0a > > Invalid magic: 73 > > 36: going from conn_parse_cmd to conn_closing > > <36 connection closed. > > > > Thanks again, > > Atul > > > > On Wednesday, April 26, 2017 at 10:30:14 PM UTC-7, Dormando wrote: > > 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: > > > >
Re: Memcached Binary protocol
Your key isn't over 256 bytes is it? On Wed, 26 Apr 2017, watul123 wrote: > Ok, thanks. Let me debug in that direction. I will update the thread with my > findings. > > BTW, if I increase the length of key and value in my test program with binary > protocol then I consistently get CONNECTION FAILURE with below output on > memcached side > <36 new binary client connection. > 36: going from conn_new_cmd to conn_waiting > 36: going from conn_waiting to conn_read > 36: going from conn_read to conn_parse_cmd > <36 Read binary protocol data: > <36 0x73 0x65 0x74 0x20 > <36 0x61 0x62 0x63 0x7a > <36 0x20 0x30 0x20 0x30 > <36 0x20 0x36 0x0d 0x0a > <36 0x76 0x61 0x6c 0x75 > <36 0x65 0x65 0x0d 0x0a > Invalid magic: 73 > 36: going from conn_parse_cmd to conn_closing > <36 connection closed. > > Thanks again, > Atul > > On Wednesday, April 26, 2017 at 10:30:14 PM UTC-7, Dormando wrote: > 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
Re: Memcached Binary protocol
Ok, thanks. Let me debug in that direction. I will update the thread with my findings. BTW, if I increase the length of key and value in my test program with binary protocol then I consistently get CONNECTION FAILURE with below output on memcached side <36 new binary client connection. 36: going from conn_new_cmd to conn_waiting 36: going from conn_waiting to conn_read 36: going from conn_read to conn_parse_cmd <36 Read binary protocol data: <360x73 0x65 0x74 0x20 <360x61 0x62 0x63 0x7a <360x20 0x30 0x20 0x30 <360x20 0x36 0x0d 0x0a <360x76 0x61 0x6c 0x75 <360x65 0x65 0x0d 0x0a Invalid magic: 73 36: going from conn_parse_cmd to conn_closing <36 connection closed. Thanks again, Atul On Wednesday, April 26, 2017 at 10:30:14 PM UTC-7, Dormando wrote: > > 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 > >
Re: Memcached Binary protocol
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.
Re: Memcached Binary protocol
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+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.
Re: Memcached Binary protocol
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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Memcached Binary protocol
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+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.
Memcached Binary protocol
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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Alignment in the binary protocol
I'm looking to implement a client for the binary protocol. I take it there is no padding between memcached requests, and that the keys are values are arbitrary lengths. So, if I send two requests, and the key for the first one is an odd number of bytes, that means the second request will start on an odd byte, and the header will be unaligned? For example, the memcached binary protocol description here uses 'Hello' as the key in the example for GET, https://code.google.com/p/memcached/wiki/MemcacheBinaryProtocol so the entire request is 29 bytes long. This means, if I want to send a second request in the same buffer, I need to start the second header at offset 29 in my buffer, correct? The NFS protocol, for example, specifies that any variable length field is padded with 0-3 zeros, so that the next field can start on a 32 bit boundary. This isn't a problem for me, but could be for some: http://blogs.msdn.com/b/oldnewthing/archive/2015/01/16/10586692.aspx -- --- 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.
Re: Multi-get implementation in binary protocol
The first is correct -- mcrouters won't send out multi-gets. Specfically, mcrouter will accept multi-gets on the server-side. That is, it will correctly parse a command like get key1 key2 key3\r\n), but when it sends the requests out, it will send them out as get key1\r\nget key2\r\nget key3\r\n, even if they all go to the same memcached server. We considered changing this a few times, but found out it increased complexity significantly and really didn't matter for the way we used memcache at Facebook. On Mon, Jan 5, 2015 at 1:30 PM, Yongming Shen symi...@gmail.com wrote: Hi Ryan, by mcrouter doesn't even support multi-gets on the client side, do you mean mcrouters won't send multi-gets to memcached servers, or frontend servers won't send multi-gets to mcrouters, or both? On Wednesday, May 7, 2014 5:10:15 PM UTC-4, Ryan McElroy wrote: At least in my experience at Facebook, 1 request != 1 packet. That is, if you send several/many requests to the same memcached box quickly, they will tend to go out in the same packet or group of packets, so you still get the benefits of fewer packets (and in fact, we take advantage of this because it is very important at very high request rates -- eg, over 1M gets per second). The same thing happens on reply -- the results tend to come back in just one packet (or more, if the replies are larger than a packet). At Facebook, our main way of talking to memcached (mcrouter) doesn't even support multi-gets on the client side, and it *doesn't matter* because the batching happens anyway. I don't have any experience with the memcached-defined binary protocol, but I think there's probably something similar going on here. You can verify by using a tool like tcpdump or ngrep to see what goes into each packet when you do a series of gets of the same box over the binary protocol. My bet is that you'll see them going in the same packet (as long as there aren't any delays in sending them out from your client application). That being said, I'd love to see what you learn if you do this experiment. Cheers, ~Ryan On Wed, May 7, 2014 at 1:24 AM, Byung-chul Hong byungch...@gmail.com wrote: Hello, For now, I'm trying to evaluate the performance of memcached server by using several client workloads. I have a question about multi-get implementation in binary protocol. As I know, in ascii protocol, we can send multiple keys in a single request packet to implement multi-get. But, in a binary protocol, it seems that we should send multiple request packets (one request packet per key) to implement multi-get. Even though we send multiple getQ, then sends get for the last key, we only can save the number of response packets only for cache miss. If I understand correctly, multi-get in binary protocol cannot reduce the number of request packets, and it also cannot reduce the number of response packets if hit-ratio is very high (like 99% get hit). If the performance bottleneck is on the network side not on the CPU, I think reducing the number of packets is still very important, but I don't understand why the binary protocol doesn't care about this. I missed something? Thanks in advance, Byungchul. -- --- 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.
Re: Multi-get implementation in binary protocol
Hi Ryan, by mcrouter doesn't even support multi-gets on the client side, do you mean mcrouters won't send multi-gets to memcached servers, or frontend servers won't send multi-gets to mcrouters, or both? On Wednesday, May 7, 2014 5:10:15 PM UTC-4, Ryan McElroy wrote: At least in my experience at Facebook, 1 request != 1 packet. That is, if you send several/many requests to the same memcached box quickly, they will tend to go out in the same packet or group of packets, so you still get the benefits of fewer packets (and in fact, we take advantage of this because it is very important at very high request rates -- eg, over 1M gets per second). The same thing happens on reply -- the results tend to come back in just one packet (or more, if the replies are larger than a packet). At Facebook, our main way of talking to memcached (mcrouter) doesn't even support multi-gets on the client side, and it *doesn't matter* because the batching happens anyway. I don't have any experience with the memcached-defined binary protocol, but I think there's probably something similar going on here. You can verify by using a tool like tcpdump or ngrep to see what goes into each packet when you do a series of gets of the same box over the binary protocol. My bet is that you'll see them going in the same packet (as long as there aren't any delays in sending them out from your client application). That being said, I'd love to see what you learn if you do this experiment. Cheers, ~Ryan On Wed, May 7, 2014 at 1:24 AM, Byung-chul Hong byungch...@gmail.com javascript: wrote: Hello, For now, I'm trying to evaluate the performance of memcached server by using several client workloads. I have a question about multi-get implementation in binary protocol. As I know, in ascii protocol, we can send multiple keys in a single request packet to implement multi-get. But, in a binary protocol, it seems that we should send multiple request packets (one request packet per key) to implement multi-get. Even though we send multiple getQ, then sends get for the last key, we only can save the number of response packets only for cache miss. If I understand correctly, multi-get in binary protocol cannot reduce the number of request packets, and it also cannot reduce the number of response packets if hit-ratio is very high (like 99% get hit). If the performance bottleneck is on the network side not on the CPU, I think reducing the number of packets is still very important, but I don't understand why the binary protocol doesn't care about this. I missed something? Thanks in advance, Byungchul. -- --- 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.
Re: Issue 275 in memcached: binary protocol TOUCH,GAT,GATQ bug
Comment #10 on issue 275 by semnan...@gmail.com: binary protocol TOUCH,GAT,GATQ bug https://code.google.com/p/memcached/issues/detail?id=275 not fixed i use install make test and give me this page link. i send using php test poster to qa. please check it. debian wheezy dot deb memcached 5.5.17-1~dotdeb.1 -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings -- --- 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.
Re: Issue 275 in memcached: binary protocol TOUCH,GAT,GATQ bug
Comment #11 on issue 275 by dorma...@rydia.net: binary protocol TOUCH,GAT,GATQ bug https://code.google.com/p/memcached/issues/detail?id=275 that's not a version of memcached. -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings -- --- 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.
Re: Multi-get implementation in binary protocol
Hello, Ryan, dormando, Thanks a lot for the clear explanation and the comments. I'm trying to find out how many requests I can batch as a muli-get within the allowed latency. I think multi-get has many advantages, the only penalty is the longer latency as pointed out in the above answer. But, the longer latency may not be a real issue unless it exceeds some threshold that the end users can notice. So, now I'm trying to use multi-get as much as possible. Actually, I have thought that Binary protocol would be always better than ascii protocol since binary protocol can reduce the burden of parsing in the Server side, but it seems that I need to test both cases. Thanks again for the comments, and I will share the result if I get some interesting or useful data. Byungchul. 2014-05-08 9:30 GMT+09:00 dormando dorma...@rydia.net: Hello, For now, I'm trying to evaluate the performance of memcached server by using several client workloads. I have a question about multi-get implementation in binary protocol. As I know, in ascii protocol, we can send multiple keys in a single request packet to implement multi-get. But, in a binary protocol, it seems that we should send multiple request packets (one request packet per key) to implement multi-get. Even though we send multiple getQ, then sends get for the last key, we only can save the number of response packets only for cache miss. If I understand correctly, multi-get in binary protocol cannot reduce the number of request packets, and it also cannot reduce the number of response packets if hit-ratio is very high (like 99% get hit). If the performance bottleneck is on the network side not on the CPU, I think reducing the number of packets is still very important, but I don't understand why the binary protocol doesn't care about this. I missed something? you're right, it sucks. I was never happy with it, but haven't had time to add adjustments to the protocol for this. To note, with .19 some inefficiencies with the protocol were lifted, and most network cards are fast enough for most situations, even if it's one packet per response (and for large enough responses they split into multiple packets, anyway). The reason why this was done is for latency and streaming of responses: - In ascii multiget, I can send 10,000 keys, then I'm forced to wait for the server to look up all of the keys before sending its responses, this isn't typically very high but there's some latency to it. - In binary multiget, the responses are sent back as it receives them from the network more or less. This reduces the latency to when you start seeing responses, regardless of how large your multiget is. this is useful if you have a kind of client which can start processing responses in a streaming fashion. This potentially reduces the total time to render your response since you can keep the CPU busy unmarshalling responses instead of sleeping. However, it should have some tunables: One where it at least does one write per complete packet (TCP_CORK'ed, or similar), and one where it buffers up to some size. In my tests I can get ascii multiget up to 16.2 million keys/sec, but (with the fixes in .19) binprot caps out at 4.6m and is spending all of its time calling sendmsg(). Most people need far, far less than that, so the binprot as is should be okay though. The code isn't too friendly to this and there're other higher priority things I'd like to get done sooner. The relatively few number of people who do 500,000+ requests per second in binprot (they're almost always ascii at that scale) is the other reason. -- --- You received this message because you are subscribed to a topic in the Google Groups memcached group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/memcached/QwjEftFhtCY/unsubscribe. To unsubscribe from this group and all its topics, 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.
Re: Multi-get implementation in binary protocol
Unfortunately binprot isn't that much faster processing wise... what it does give you is a bunch of safe features (batching set's, mixing sets/gets and the like). You *can* reduce the packet load on the server a bit by ensuring your client is actually batching the binary multiget packets together, then it's only the server increasing the packet load... On Fri, 9 May 2014, Byung-chul Hong wrote: Hello, Ryan, dormando, Thanks a lot for the clear explanation and the comments. I'm trying to find out how many requests I can batch as a muli-get within the allowed latency. I think multi-get has many advantages, the only penalty is the longer latency as pointed out in the above answer. But, the longer latency may not be a real issue unless it exceeds some threshold that the end users can notice. So, now I'm trying to use multi-get as much as possible. Actually, I have thought that Binary protocol would be always better than ascii protocol since binary protocol can reduce the burden of parsing in the Server side, but it seems that I need to test both cases. Thanks again for the comments, and I will share the result if I get some interesting or useful data. Byungchul. 2014-05-08 9:30 GMT+09:00 dormando dorma...@rydia.net: Hello, For now, I'm trying to evaluate the performance of memcached server by using several client workloads. I have a question about multi-get implementation in binary protocol. As I know, in ascii protocol, we can send multiple keys in a single request packet to implement multi-get. But, in a binary protocol, it seems that we should send multiple request packets (one request packet per key) to implement multi-get. Even though we send multiple getQ, then sends get for the last key, we only can save the number of response packets only for cache miss. If I understand correctly, multi-get in binary protocol cannot reduce the number of request packets, and it also cannot reduce the number of response packets if hit-ratio is very high (like 99% get hit). If the performance bottleneck is on the network side not on the CPU, I think reducing the number of packets is still very important, but I don't understand why the binary protocol doesn't care about this. I missed something? you're right, it sucks. I was never happy with it, but haven't had time to add adjustments to the protocol for this. To note, with .19 some inefficiencies with the protocol were lifted, and most network cards are fast enough for most situations, even if it's one packet per response (and for large enough responses they split into multiple packets, anyway). The reason why this was done is for latency and streaming of responses: - In ascii multiget, I can send 10,000 keys, then I'm forced to wait for the server to look up all of the keys before sending its responses, this isn't typically very high but there's some latency to it. - In binary multiget, the responses are sent back as it receives them from the network more or less. This reduces the latency to when you start seeing responses, regardless of how large your multiget is. this is useful if you have a kind of client which can start processing responses in a streaming fashion. This potentially reduces the total time to render your response since you can keep the CPU busy unmarshalling responses instead of sleeping. However, it should have some tunables: One where it at least does one write per complete packet (TCP_CORK'ed, or similar), and one where it buffers up to some size. In my tests I can get ascii multiget up to 16.2 million keys/sec, but (with the fixes in .19) binprot caps out at 4.6m and is spending all of its time calling sendmsg(). Most people need far, far less than that, so the binprot as is should be okay though. The code isn't too friendly to this and there're other higher priority things I'd like to get done sooner. The relatively few number of people who do 500,000+ requests per second in binprot (they're almost always ascii at that scale) is the other reason. -- --- You received this message because you are subscribed to a topic in the Google Groups memcached group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/memcached/QwjEftFhtCY/unsubscribe. To unsubscribe from this group and all its topics, 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. -- --- You received this message because you are subscribed to the Google Groups memcached group. To unsubscribe from
Multi-get implementation in binary protocol
Hello, For now, I'm trying to evaluate the performance of memcached server by using several client workloads. I have a question about multi-get implementation in binary protocol. As I know, in ascii protocol, we can send multiple keys in a single request packet to implement multi-get. But, in a binary protocol, it seems that we should send multiple request packets (one request packet per key) to implement multi-get. Even though we send multiple getQ, then sends get for the last key, we only can save the number of response packets only for cache miss. If I understand correctly, multi-get in binary protocol cannot reduce the number of request packets, and it also cannot reduce the number of response packets if hit-ratio is very high (like 99% get hit). If the performance bottleneck is on the network side not on the CPU, I think reducing the number of packets is still very important, but I don't understand why the binary protocol doesn't care about this. I missed something? Thanks in advance, Byungchul. -- --- 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.
Re: Multi-get implementation in binary protocol
At least in my experience at Facebook, 1 request != 1 packet. That is, if you send several/many requests to the same memcached box quickly, they will tend to go out in the same packet or group of packets, so you still get the benefits of fewer packets (and in fact, we take advantage of this because it is very important at very high request rates -- eg, over 1M gets per second). The same thing happens on reply -- the results tend to come back in just one packet (or more, if the replies are larger than a packet). At Facebook, our main way of talking to memcached (mcrouter) doesn't even support multi-gets on the client side, and it *doesn't matter* because the batching happens anyway. I don't have any experience with the memcached-defined binary protocol, but I think there's probably something similar going on here. You can verify by using a tool like tcpdump or ngrep to see what goes into each packet when you do a series of gets of the same box over the binary protocol. My bet is that you'll see them going in the same packet (as long as there aren't any delays in sending them out from your client application). That being said, I'd love to see what you learn if you do this experiment. Cheers, ~Ryan On Wed, May 7, 2014 at 1:24 AM, Byung-chul Hong byungchul.h...@gmail.comwrote: Hello, For now, I'm trying to evaluate the performance of memcached server by using several client workloads. I have a question about multi-get implementation in binary protocol. As I know, in ascii protocol, we can send multiple keys in a single request packet to implement multi-get. But, in a binary protocol, it seems that we should send multiple request packets (one request packet per key) to implement multi-get. Even though we send multiple getQ, then sends get for the last key, we only can save the number of response packets only for cache miss. If I understand correctly, multi-get in binary protocol cannot reduce the number of request packets, and it also cannot reduce the number of response packets if hit-ratio is very high (like 99% get hit). If the performance bottleneck is on the network side not on the CPU, I think reducing the number of packets is still very important, but I don't understand why the binary protocol doesn't care about this. I missed something? Thanks in advance, Byungchul. -- --- 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.
Re: Multi-get implementation in binary protocol
Hello, For now, I'm trying to evaluate the performance of memcached server by using several client workloads. I have a question about multi-get implementation in binary protocol. As I know, in ascii protocol, we can send multiple keys in a single request packet to implement multi-get. But, in a binary protocol, it seems that we should send multiple request packets (one request packet per key) to implement multi-get. Even though we send multiple getQ, then sends get for the last key, we only can save the number of response packets only for cache miss. If I understand correctly, multi-get in binary protocol cannot reduce the number of request packets, and it also cannot reduce the number of response packets if hit-ratio is very high (like 99% get hit). If the performance bottleneck is on the network side not on the CPU, I think reducing the number of packets is still very important, but I don't understand why the binary protocol doesn't care about this. I missed something? you're right, it sucks. I was never happy with it, but haven't had time to add adjustments to the protocol for this. To note, with .19 some inefficiencies with the protocol were lifted, and most network cards are fast enough for most situations, even if it's one packet per response (and for large enough responses they split into multiple packets, anyway). The reason why this was done is for latency and streaming of responses: - In ascii multiget, I can send 10,000 keys, then I'm forced to wait for the server to look up all of the keys before sending its responses, this isn't typically very high but there's some latency to it. - In binary multiget, the responses are sent back as it receives them from the network more or less. This reduces the latency to when you start seeing responses, regardless of how large your multiget is. this is useful if you have a kind of client which can start processing responses in a streaming fashion. This potentially reduces the total time to render your response since you can keep the CPU busy unmarshalling responses instead of sleeping. However, it should have some tunables: One where it at least does one write per complete packet (TCP_CORK'ed, or similar), and one where it buffers up to some size. In my tests I can get ascii multiget up to 16.2 million keys/sec, but (with the fixes in .19) binprot caps out at 4.6m and is spending all of its time calling sendmsg(). Most people need far, far less than that, so the binprot as is should be okay though. The code isn't too friendly to this and there're other higher priority things I'd like to get done sooner. The relatively few number of people who do 500,000+ requests per second in binprot (they're almost always ascii at that scale) is the other reason. -- --- 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.
Re: Issue 320 in memcached: increment with initial value using binary protocol always returns 22 bytes value with get
Updates: Status: Fixed Comment #2 on issue 320 by dorma...@rydia.net: increment with initial value using binary protocol always returns 22 bytes value with get http://code.google.com/p/memcached/issues/detail?id=320 Merged fix. -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings -- --- 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/groups/opt_out.
Re: Issue 275 in memcached: binary protocol TOUCH,GAT,GATQ bug
Updates: Status: Fixed Comment #9 on issue 275 by dorma...@rydia.net: binary protocol TOUCH,GAT,GATQ bug http://code.google.com/p/memcached/issues/detail?id=275 this got merged a year ago... forgot to close the issue. doing so now. -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings -- --- 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/groups/opt_out.
Re: Strange behaviour on get-multi over binary protocol
Hi, On Feb 18, 2013, at 7:11 PM, dormando dorma...@rydia.net wrote: 1) libmemcached requests 2 keys 2) memcached responds with 1 key 3) libmemcached sends no-op packet 4) memcached responds with 2nd key, no-op packet Assuming one server and binary protocol... a single write to the socket would be made for both keys under both the binary and ascii server (assuming the keys are small enough to fit into the default buffer, which is the case assuming trunk version of memcached). The code bunches up as many requests as can be made into the buffer before flushing. When looking through the code I didn't find anything that should be fouling that up (though I did find that we were incrementing the packet counter more then what we should, but that won't really effect anything). Anyway, everything looks to be ok. Cheers, -Brian smime.p7s Description: S/MIME cryptographic signature
Re: Strange behaviour on get-multi over binary protocol
Hi, On Feb 19, 2013, at 12:14 AM, dormando dorma...@rydia.net 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 smime.p7s Description: S/MIME cryptographic signature
Re: Strange behaviour on get-multi over binary protocol
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 br...@tangent.org wrote: Hi, On Feb 19, 2013, at 12:14 AM, dormando dorma...@rydia.net 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 memcached+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Strange behaviour on get-multi over binary protocol
This is correct. You use the no-op packet to be sure you're not waiting for any more responses, since you're not going to get miss packets for missing keys. No reason for it to be a separate write/packet though. 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 br...@tangent.org wrote: Hi, On Feb 19, 2013, at 12:14 AM, dormando dorma...@rydia.net 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 memcached+unsubscr...@googlegroups.com. 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 memcached+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Strange behaviour on get-multi over binary protocol
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 dorma...@rydia.net 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 br...@tangent.org wrote: Hi, On Feb 19, 2013, at 12:14 AM, dormando dorma...@rydia.net 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 memcached+unsubscr...@googlegroups.com. 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 memcached+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Strange behaviour on get-multi over binary protocol
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 br...@tangent.org 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 dorma...@rydia.net 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 br...@tangent.org wrote: Hi, On Feb 19, 2013, at 12:14 AM, dormando dorma...@rydia.net 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 memcached+unsubscr...@googlegroups.com. 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 memcached+unsubscr...@googlegroups.com. 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 memcached+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Strange behaviour on get-multi over binary protocol
Hi guys, I'm getting a rather strange behaviour when I try to issue a get-multi on memcached, so I'm not sure this is a problem with my understanding of how the protocol was specified or if it's an issue with either pylibmc or libmemcached. What I expect: As I understand it, for multi-get, the expected communication is: 1. The client sends a getq/getkq for each desired key, in a batch; 2. The client sends a no-op request, to signal that there are no more keys to request for; 3. The server stacks the previous requests, and retrieves all existing keys within the requested ones; 4. The server responds with all retrieved keys with getq/getkq responses, in a batch; 5. The server sends a no-op response, to signal that there are no more keys to send. However, after trying to follow this behaviour in a proxy I'm building, this order of interactions is not being respected; So, what I did afterwards, to assert that something strange was going on, was to fire up Wireshark and listen for memcached requests and responses. Here's a sample of the request and response blocks sent between the client and the server: http://pastebin.ubuntu.com/1679323/ This was tested with pylibmc, in binary mode, and after setting foo to bar, and foo2 to bar2, I tried to multi-get foo and foo2. I also tested with more keys after this sample, and this is the behaviour I'm getting: 1. The client sends a getkq for each desired key, in a batch; 2. The server sends the getkq response for the first key; 3. The client sends (and the server reads) the no-op request; 4. The server sends the rest of the keys as getkq responses, in a batch; 5. The server sends the no-op request. This is really weird for me, since the first key value is responded without the server even having received the no-op request. So, I have two questions: 1. Is my understanding of how the protocol works, for multi-get, correct? The documentation I found for it ( http://code.google.com/p/memcached/wiki/BinaryProtocolRevamped) doesn't seem very up-to-date, and doesn't respect that, but I've read somewhere else (and experimented with) that no-ops are the blocks that signal an end-of-batch; 2. If my understanding is right, then is this a problem in the server or in the client? I'm guessing it's in the server, since it starts responding without even getting the no-op request. I can provide more complete details of this interaction data (with timestamps included), if you need me to. Thanks for the help, Diogo -- --- 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/groups/opt_out.
Re: Strange behaviour on get-multi over binary protocol
However, after trying to follow this behaviour in a proxy I'm building, this order of interactions is not being respected; So, what I did afterwards, to assert that something strange was going on, was to fire up Wireshark and listen for memcached requests and responses. Here's a sample of the request and response blocks sent between the client and the server: http://pastebin.ubuntu.com/1679323/ This was tested with pylibmc, in binary mode, and after setting foo to bar, and foo2 to bar2, I tried to multi-get foo and foo2. I also tested with more keys after this sample, and this is the behaviour I'm getting: 1. The client sends a getkq for each desired key, in a batch; 2. The server sends the getkq response for the first key; 3. The client sends (and the server reads) the no-op request; 4. The server sends the rest of the keys as getkq responses, in a batch; 5. The server sends the no-op request. This is really weird for me, since the first key value is responded without the server even having received the no-op request. So this is a bit weird in the documentation of the protocol but basically: The server's free to start sending responses as soon as it gets requests. The reason the no-op packet is stacked at the end (a get-non-q should work as well) is so that once you see the response to that no-op, you can be sure there're no other responses waiting. As with getq a response is optional, you don't need to look for a 'miss' response. So a client *can*: Send all key requests in one batch, along with the no-op packet in the same write. For some reason libmemcached *does*: batch all of the requests, then do the no-op in a second write? (this isn't bad, nothing's waiting on it, it just doesn't tack it on in the same write). It's a waste of a packet on the wire. Then it can read back whatever. It might look mixed up if you're doing this over localhost and there's no lag. Try it over the internet or use a qdisc to add an artificial delay. It should line up more along the way you expect. So, I have two questions: 1. Is my understanding of how the protocol works, for multi-get, correct? The documentation I found for it (http://code.google.com/p/memcached/wiki/BinaryProtocolRevamped) doesn't seem very up-to-date, and doesn't respect that, but I've read somewhere else (and experimented with) that no-ops are the blocks that signal an end-of-batch; 2. If my understanding is right, then is this a problem in the server or in the client? I'm guessing it's in the server, since it starts responding without even getting the no-op request. I can provide more complete details of this interaction data (with timestamps included), if you need me to. Thanks for the help, Have you verified that it's an actual problem, or is this just the server responded not in the same order you expect? I don't think anything's blocking by your description, but it might look that way given how split up things are. With ASCII prot the server can't start responding until it's read the newline at the end. I'd like it better if libmemcached packed that no-op, and if the server cork'ed writes so it'd at least only send completed packets unless nothing else is in the queue to process. However, like most holidays I am sad and pony-less, unless I go get that pony myself. -Dormando -- --- 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/groups/opt_out.
Re: Strange behaviour on get-multi over binary protocol
Hi Dormando, So, I've tested Memcached by sending direct byte blocks to it in the order I expected it to behave, and indeed it works, as you said it would: https://gist.github.com/diogobaeder/4982425 I have no clue why libmemcached does that switch in the middle, but I understood what you said about not expecting things to happen in an exact order - like, the server can start responding at any moment after it receives the first request block -. So, I guess what I need to do now is to redesign my proxy to consider this flexible ordering, and not do this whole multi-get interaction in one shot, but distribute it into events. Maybe something that would be nice is to update that protocol documentation with the things you told me, this would enlighten the path of whoever wants to adventure in this part of building a memcached client, what do you think? For example, it says nothing about no-op signaling as end-of-batch. Thanks for the help, man! :-) Cheers, Diogo On Monday, February 18, 2013 9:45:33 PM UTC-3, Dormando wrote: However, after trying to follow this behaviour in a proxy I'm building, this order of interactions is not being respected; So, what I did afterwards, to assert that something strange was going on, was to fire up Wireshark and listen for memcached requests and responses. Here's a sample of the request and response blocks sent between the client and the server: http://pastebin.ubuntu.com/1679323/ This was tested with pylibmc, in binary mode, and after setting foo to bar, and foo2 to bar2, I tried to multi-get foo and foo2. I also tested with more keys after this sample, and this is the behaviour I'm getting: 1. The client sends a getkq for each desired key, in a batch; 2. The server sends the getkq response for the first key; 3. The client sends (and the server reads) the no-op request; 4. The server sends the rest of the keys as getkq responses, in a batch; 5. The server sends the no-op request. This is really weird for me, since the first key value is responded without the server even having received the no-op request. So this is a bit weird in the documentation of the protocol but basically: The server's free to start sending responses as soon as it gets requests. The reason the no-op packet is stacked at the end (a get-non-q should work as well) is so that once you see the response to that no-op, you can be sure there're no other responses waiting. As with getq a response is optional, you don't need to look for a 'miss' response. So a client *can*: Send all key requests in one batch, along with the no-op packet in the same write. For some reason libmemcached *does*: batch all of the requests, then do the no-op in a second write? (this isn't bad, nothing's waiting on it, it just doesn't tack it on in the same write). It's a waste of a packet on the wire. Then it can read back whatever. It might look mixed up if you're doing this over localhost and there's no lag. Try it over the internet or use a qdisc to add an artificial delay. It should line up more along the way you expect. So, I have two questions: 1. Is my understanding of how the protocol works, for multi-get, correct? The documentation I found for it ( http://code.google.com/p/memcached/wiki/BinaryProtocolRevamped) doesn't seem very up-to-date, and doesn't respect that, but I've read somewhere else (and experimented with) that no-ops are the blocks that signal an end-of-batch; 2. If my understanding is right, then is this a problem in the server or in the client? I'm guessing it's in the server, since it starts responding without even getting the no-op request. I can provide more complete details of this interaction data (with timestamps included), if you need me to. Thanks for the help, Have you verified that it's an actual problem, or is this just the server responded not in the same order you expect? I don't think anything's blocking by your description, but it might look that way given how split up things are. With ASCII prot the server can't start responding until it's read the newline at the end. I'd like it better if libmemcached packed that no-op, and if the server cork'ed writes so it'd at least only send completed packets unless nothing else is in the queue to process. However, like most holidays I am sad and pony-less, unless I go get that pony myself. -Dormando -- --- 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/groups/opt_out.
Re: Strange behaviour on get-multi over binary protocol
Hi, On Feb 18, 2013, at 6:03 PM, Diogo Baeder diogobae...@gmail.com wrote: I have no clue why libmemcached does that switch in the middle, but I understood what you said about not expecting things to happen in an exact order Are you sure the data is on the same server? Libmemcached responds back with whatever returned first, which when spread across a number of servers,... well who knows who might respond back the quickest. If you want order, then issue a single blocking get (one after another). Cheers, -Brian smime.p7s Description: S/MIME cryptographic signature
Re: Strange behaviour on get-multi over binary protocol
On Feb 18, 2013, at 6:03 PM, Diogo Baeder diogobae...@gmail.com wrote: I have no clue why libmemcached does that switch in the middle, but I understood what you said about not expecting things to happen in an exact order Are you sure the data is on the same server? Libmemcached responds back with whatever returned first, which when spread across a number of servers,... well who knows who might respond back the quickest. If you want order, then issue a single blocking get (one after another). That's not quite what he meant. He's seeing: 1) libmemcached requests 2 keys 2) memcached responds with 1 key 3) libmemcached sends no-op packet 4) memcached responds with 2nd key, no-op packet This is just due to the test being run over localhost. libmemcached sends the final no-op packet in a second write, so memcached has a chance to start responding before receiving it. If libmemcached sent everything as one write he probably wouldn't have noticed until testing with much larger multigets. It's not a problem, it's just not what he was expecting I guess? The only actual problem here is both libmemcached and memcached generating a nonoptimal amount of syscalls and wire packets. -- --- 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/groups/opt_out.
Re: Strange behaviour on get-multi over binary protocol
Yep, agreed, Dormando, not a problem, just different from my initial expectations. I'll just have to figure out how to use Tornado in my favor, to build this part, and deal correctly with the asynchronicity. :-) Cheers! __ Diogo Baeder http://diogobaeder.com.br On Tue, Feb 19, 2013 at 12:11 AM, dormando dorma...@rydia.net wrote: On Feb 18, 2013, at 6:03 PM, Diogo Baeder diogobae...@gmail.com wrote: I have no clue why libmemcached does that switch in the middle, but I understood what you said about not expecting things to happen in an exact order Are you sure the data is on the same server? Libmemcached responds back with whatever returned first, which when spread across a number of servers,... well who knows who might respond back the quickest. If you want order, then issue a single blocking get (one after another). That's not quite what he meant. He's seeing: 1) libmemcached requests 2 keys 2) memcached responds with 1 key 3) libmemcached sends no-op packet 4) memcached responds with 2nd key, no-op packet This is just due to the test being run over localhost. libmemcached sends the final no-op packet in a second write, so memcached has a chance to start responding before receiving it. If libmemcached sent everything as one write he probably wouldn't have noticed until testing with much larger multigets. It's not a problem, it's just not what he was expecting I guess? The only actual problem here is both libmemcached and memcached generating a nonoptimal amount of syscalls and wire packets. -- --- 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/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 memcached+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Strange behaviour on get-multi over binary protocol
Guess what: I just built a fake Memcached server, to answer hardcoded values (same as before) to a get_multi op for pylibmc, with normally ordered batches (2 reqs, 1 noop, 2 resp, 1 noop), and it worked. So, in the end, it seems like forcing the ordering is not what is causing me troubles, it's something else that is failing to me that I didn't yet notice. In other words, libmemcached seems to play just fine with ordered batches. Not sure if this adds anything here, but I thought you might want to know. :-) Cheers! __ Diogo Baeder http://diogobaeder.com.br On Tue, Feb 19, 2013 at 12:15 AM, Diogo Baeder diogobae...@gmail.comwrote: Yep, agreed, Dormando, not a problem, just different from my initial expectations. I'll just have to figure out how to use Tornado in my favor, to build this part, and deal correctly with the asynchronicity. :-) Cheers! __ Diogo Baeder http://diogobaeder.com.br On Tue, Feb 19, 2013 at 12:11 AM, dormando dorma...@rydia.net wrote: On Feb 18, 2013, at 6:03 PM, Diogo Baeder diogobae...@gmail.com wrote: I have no clue why libmemcached does that switch in the middle, but I understood what you said about not expecting things to happen in an exact order Are you sure the data is on the same server? Libmemcached responds back with whatever returned first, which when spread across a number of servers,... well who knows who might respond back the quickest. If you want order, then issue a single blocking get (one after another). That's not quite what he meant. He's seeing: 1) libmemcached requests 2 keys 2) memcached responds with 1 key 3) libmemcached sends no-op packet 4) memcached responds with 2nd key, no-op packet This is just due to the test being run over localhost. libmemcached sends the final no-op packet in a second write, so memcached has a chance to start responding before receiving it. If libmemcached sent everything as one write he probably wouldn't have noticed until testing with much larger multigets. It's not a problem, it's just not what he was expecting I guess? The only actual problem here is both libmemcached and memcached generating a nonoptimal amount of syscalls and wire packets. -- --- 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/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 memcached+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Issue 275 in memcached: binary protocol TOUCH,GAT,GATQ bug
Comment #7 on issue 275 by uzza...@gmail.com: binary protocol TOUCH,GAT,GATQ bug http://code.google.com/p/memcached/issues/detail?id=275 Here is a patch that solves the problem. process_bin_touch() was reading only header without extra fields, so exptime was always 0. Attachments: binary-touch-exptime.patch 635 bytes
Re: Issue 275 in memcached: binary protocol TOUCH,GAT,GATQ bug
Comment #8 on issue 275 by uzza...@gmail.com: binary protocol TOUCH,GAT,GATQ bug http://code.google.com/p/memcached/issues/detail?id=275 P.S. Send pull request at github with the same code.
Re: About verbosity and touch command of the binary protocol
Got the same problem with binary touch using memcached 1.4.13. On Saturday, January 7, 2012 8:54:19 AM UTC+3, Bongjae Chang wrote: Hi, I am trying to implement a memcached client based on Java for improving performance. Most of commands worked fine. But when I tested verbosity, touch and gat command with binary protocol, it seemed that they didn't work correctly. * Memcached v1.4.10 1. verbosity When I sent the request to the server, the server returned unknown command error.(Text protocol works fine) (I made the request based on http://code.google.com/p/memcached/wiki/BinaryProtocolRevamped#Verbosity ) Here are headers which the server received and sent to the client. 22 Read binary protocol data: 220x80 0x1b 0x00 0x00 220x04 0x00 0x00 0x00 220x00 0x00 0x00 0x04 220x00 0x00 0x00 0x00 220x00 0x00 0x00 0x00 220x00 0x00 0x00 0x00 22 Writing an error: Unknown command 22 Writing bin response: 22 0x81 0x1b 0x00 0x00 22 0x00 0x00 0x00 0x81 22 0x00 0x00 0x00 0x0f 22 0x00 0x00 0x00 0x00 22 0x00 0x00 0x00 0x00 22 0x00 0x00 0x00 0x00 2. touch and gat When I sent touch and gat requests with expiration timeout to the server, the server returned No_Error status. But it seemed that the new expiration was not applied.(I set new expiration timeout to be 1 second in touch and gat command as extras request, and waited for 2 sec, and got the key. The key and value were still alive though I expected key-not-found error) I also read http://code.google.com/p/memcached/wiki/BinaryProtocolRevamped#Touch,_GAT_and_GATQ . If I am missing any issues or misunderstanding these protocols, please advice me and let me know. Thanks! PS) When I used xmemcached java client, results were also same to my client. And I sent this mail to memcached@googlegroups.com first, but it seemed that this message wasn't registered in this groups. So I tried to register this again by web site directly. Regards, Bongjae Chang
Re: Issue 275 in memcached: binary protocol TOUCH,GAT,GATQ bug
Comment #4 on issue 275 by dorma...@rydia.net: binary protocol TOUCH,GAT,GATQ bug http://code.google.com/p/memcached/issues/detail?id=275 If you sleep for 2 seconds instead of one, it should work. Memcached's internal clock updates once per second, so if you want to see things change at around the second level it becomes unreliable.
Re: Issue 275 in memcached: binary protocol TOUCH,GAT,GATQ bug
Comment #5 on issue 275 by mojid...@gmail.com: binary protocol
TOUCH,GAT,GATQ bug
http://code.google.com/p/memcached/issues/detail?id=275
cache.set(x, xxx, 3);
cache.touch(x, 1)
while(true){
TimeUnit.SECONDS.sleep(1);
System.out.println(cache.get(x));
}
===output==
xxx
xxx
xxx
xxx
xxx
.
.
I run a few minutes, It still did not expired
Re: Issue 275 in memcached: binary protocol TOUCH,GAT,GATQ bug
Comment #1 on issue 275 by ingen...@gmail.com: binary protocol TOUCH,GAT,GATQ bug http://code.google.com/p/memcached/issues/detail?id=275 What server is in use? There is no checking of server responses.
About verbosity and touch command of the binary protocol
Hi, I am trying to implement a memcached client based on Java for improving performance. Most of commands worked fine. But when I tested verbosity, touch and gat command with binary protocol, it seemed that they didn't work correctly. * Memcached v1.4.10 1. verbosity When I sent the request to the server, the server returned unknown command error.(Text protocol works fine) (I made the request based on http://code.google.com/p/memcached/wiki/BinaryProtocolRevamped#Verbosity ) Here are headers which the server received and sent to the client. 22 Read binary protocol data: 220x80 0x1b 0x00 0x00 220x04 0x00 0x00 0x00 220x00 0x00 0x00 0x04 220x00 0x00 0x00 0x00 220x00 0x00 0x00 0x00 220x00 0x00 0x00 0x00 22 Writing an error: Unknown command 22 Writing bin response: 22 0x81 0x1b 0x00 0x00 22 0x00 0x00 0x00 0x81 22 0x00 0x00 0x00 0x0f 22 0x00 0x00 0x00 0x00 22 0x00 0x00 0x00 0x00 22 0x00 0x00 0x00 0x00 2. touch and gat When I sent touch and gat requests with expiration timeout to the server, the server returned No_Error status. But it seemed that the new expiration was not applied.(I set new expiration timeout to be 1 second in touch and gat command as extras request, and waited for 2 sec, and got the key. The key and value were still alive though I expected key-not-found error) I also read http://code.google.com/p/memcached/wiki/BinaryProtocolRevamped#Touch,_GAT_and_GATQ . If I am missing any issues or misunderstanding these protocols, please advice me and let me know. Thanks! PS) When I used xmemcached java client, results were also same to my client. And I sent this mail to memcached@googlegroups.com first, but it seemed that this message wasn't registered in this groups. So I tried to register this again by web site directly. Regards, Bongjae Chang
About verbosity and touch in binary protocol
Hi, I am trying to implement a memcached client based on Java for improving performance. When I tested verbosity, touch and gat command with binary protocol, it seemed that they didn't work correctly. * Memcached v1.4.10 1. verbosity When I sent the request to the server, the server returned unknown command error.(Text protocol works fine) (I made the request based on http://code.google.com/p/memcached/wiki/BinaryProtocolRevamped#Verbosity ) Here are headers which the server received and sent to the client. 22 Read binary protocol data: 220x80 0x1b 0x00 0x00 220x04 0x00 0x00 0x00 220x00 0x00 0x00 0x04 220x00 0x00 0x00 0x00 220x00 0x00 0x00 0x00 220x00 0x00 0x00 0x00 22 Writing an error: Unknown command 22 Writing bin response: 22 0x81 0x1b 0x00 0x00 22 0x00 0x00 0x00 0x81 22 0x00 0x00 0x00 0x0f 22 0x00 0x00 0x00 0x00 22 0x00 0x00 0x00 0x00 22 0x00 0x00 0x00 0x00 2. touch and gat When I sent touch and gat requests with expiration to the server, the server returned No_Error status. But it seemed that the new expiration was not applied. I also read http://code.google.com/p/memcached/wiki/BinaryProtocolRevamped#Touch,_GAT_an d_GATQ . If I am missing any issues or misunderstanding these protocols, please advice me and let me know. Thanks! PS) When I used xmemcached java client, results were also same to my client. Regards, Bongjae Chang
Re: Issue 107 in memcached: binary protocol can only parse 1 command within a recieved udp / tcp buffer
Updates: Status: Fixed Comment #2 on issue 107 by dorma...@rydia.net: binary protocol can only parse 1 command within a recieved udp / tcp buffer http://code.google.com/p/memcached/issues/detail?id=107 wow this is ancient. fix for this is currently sitting in my for_148 branch and will be in 1.4.8. hope it's fixed, as I wasn't able to really reproduce the problem with the test script. The code certainly looked wrong though.
Re: Issue 106 in memcached: binary protocol parsing can cause memcached server lockup
Updates: Status: Fixed Comment #12 on issue 106 by dorma...@rydia.net: binary protocol parsing can cause memcached server lockup http://code.google.com/p/memcached/issues/detail?id=106 think this was merged up. closing.
Re: Issue 106 in memcached: binary protocol parsing can cause memcached server lockup
Comment #10 on issue 106 by dorma...@rydia.net: binary protocol parsing can cause memcached server lockup http://code.google.com/p/memcached/issues/detail?id=106 The incoming packet is consumed in try_read_udp(), so if you get into a conn_close state after reading one packet, calling an empty recvfrom will consume the *next*, unseen packet. Unless there is some case you're talking about which causes the next packet on the wire to be an error? I did push my tree though, so take a look at what I ended up with: https://github.com/dormando/memcached/commit/954f6dddc41c80d2e625bce63744df5556a425bb ... I can't break it with your tests anymore, and it doesn't hang before responding. If you look at how TCP connections are intialized, you'll see they're set to conn_new_cmd, but the UDP listeners are initialized to conn_read. The latter makes sense in the flow. Either way, can you try the patch and see if you can still break it? :)
Re: Issue 106 in memcached: binary protocol parsing can cause memcached server lockup
Comment #11 on issue 106 by pi3or...@gmail.com: binary protocol parsing can cause memcached server lockup http://code.google.com/p/memcached/issues/detail?id=106 I think you are right. In my first patch (Comment 1), the recvfrom() call is critical because in that situation, if a UDP socket is in conn_closing state, it will never be recovered, all incoming packets should be dropped. If we recover its state to conn_read, there's no need for the recvfrom() again.
Re: Issue 106 in memcached: binary protocol parsing can cause memcached server lockup
Updates: Status: Started Owner: trond.no...@gmail.com Comment #8 on issue 106 by dorma...@rydia.net: binary protocol parsing can cause memcached server lockup http://code.google.com/p/memcached/issues/detail?id=106 I just pulled a patch similar to this into my 1.4.7 tree. This was confusing me a bit... the extra recvfrom seemed pointless and it'd hang while running. The test from #158 would spin out of control without the recvfrom. But the initial state of a UDP connection is actually conn_read, not conn_new_cmd. Using the correct state makes it find the next UDP packet and throw it away properly. Still iffy on the rbytes bit, but so long as multiple command parsing works (which I don't think it does now anyway), that should be correct. Punting to trond in case he wants to port this properly to 1.6.0, or take a look at least. I'll be pushing my for_147 branch to github at some point.
Re: Issue 106 in memcached: binary protocol parsing can cause memcached server lockup
Comment #6 on issue 106 by dorma...@rydia.net: binary protocol parsing can cause memcached server lockup http://code.google.com/p/memcached/issues/detail?id=106 Can you issue a patch against 1.6.0-beta1? Or were you talking about 1.4.5, not 1.3.5?
Re: Issue 106 in memcached: binary protocol parsing can cause memcached server lockup
Comment #7 on issue 106 by pi3or...@gmail.com: binary protocol parsing can
cause memcached server lockup
http://code.google.com/p/memcached/issues/detail?id=106
Ok. 1.6.0-beta1 still suffer from this problem, the principle is similar.
Following patch solve it (I thought).
--- ./daemon/memcached.ori.c2011-06-28 09:43:45.12072 +0800
+++ ./daemon/memcached.c2011-06-28 09:57:18.39071 +0800
@@ -689,13 +689,19 @@
c-sasl_conn = NULL;
}
-c-engine_storage = NULL;
-c-tap_iterator = NULL;
-c-thread = NULL;
-assert(c-next == NULL);
-c-ascii_cmd = NULL;
-c-sfd = INVALID_SOCKET;
-c-tap_nack_mode = false;
+if (IS_UDP(c-transport)) {
+recvfrom(c-sfd, NULL, 0, 0, NULL, NULL);
+conn_set_state(c, conn_new_cmd);
+} else {
+c-sfd = INVALID_SOCKET;
+c-engine_storage = NULL;
+c-tap_iterator = NULL;
+c-thread = NULL;
+assert(c-next == NULL);
+c-ascii_cmd = NULL;
+c-tap_nack_mode = false;
+}
+
}
void conn_close(conn *c) {
@@ -4826,7 +4832,7 @@
res -= 8;
memmove(c-rbuf, c-rbuf + 8, res);
-c-rbytes += res;
+c-rbytes = res;
c-rcurr = c-rbuf;
return READ_DATA_RECEIVED;
}
Re: Issue 187 in memcached: no example for stats cachedump in binary-Protocol
Comment #2 on issue 187 by trond.no...@gmail.com: no example for stats cachedump in binary-Protocol http://code.google.com/p/memcached/issues/detail?id=187 You should use the key field, but I don't think memcached 1.4.5 supports stats cachedump in the binary protocol
Re: Issue 187 in memcached: no example for stats cachedump in binary-Protocol
Comment #4 on issue 187 by sarow...@gmail.com: no example for stats cachedump in binary-Protocol http://code.google.com/p/memcached/issues/detail?id=187 stats cachedump has two arguments , one for slab_id ,one for limit . I have use the key field , but it seems nothing changed . May be memcached 1.4.5 not supports it , wait for office reply .
Re: Issue 187 in memcached: no example for stats cachedump in binary-Protocol
Comment #3 on issue 187 by sarow...@gmail.com: no example for stats cachedump in binary-Protocol http://code.google.com/p/memcached/issues/detail?id=187 stats cachedump has two arguments , one for slab_id ,one for limit . I have use the key field , but it seems nothing changed . May be memcached 1.4.5 not supports it , wait for office reply .
Re: Issue 187 in memcached: no example for stats cachedump in binary-Protocol
Updates: Status: Invalid Comment #5 on issue 187 by dsalli...@gmail.com: no example for stats cachedump in binary-Protocol http://code.google.com/p/memcached/issues/detail?id=187 I think the documentation is pretty clear: MUST NOT have extras. MAY have key. MUST NOT have value. Request server statistics. Without a key specified the server will respond with a default set of statistics information. Each piece of statistical information is returned in its own packet (key contains the name of the statistical item and the body contains the value in ASCII format). The sequence of return packets is terminated with a packet that contains no key and no value. -- the stat subtype goes in the key field. I do not think we should be adding examples to the protocol specification that show how to access undocumented features of memcached. If you feel strongly that we should provide an example of a key here, reopen. It won't be cachedump, though. :)
Re: Issue 187 in memcached: no example for stats cachedump in binary-Protocol
Comment #6 on issue 187 by sarow...@gmail.com: no example for stats cachedump in binary-Protocol http://code.google.com/p/memcached/issues/detail?id=187 I have read this documentation stats items , stats maps , stats settings are work well but stats cachedump has another two arguments it must stats cachedump 1 0 so i don`t know where should 1 0 place . hope you give me on example in binaryprotocol
Re: Issue 187 in memcached: no example for stats cachedump in binary-Protocol
Comment #7 on issue 187 by sarow...@gmail.com: no example for stats cachedump in binary-Protocol http://code.google.com/p/memcached/issues/detail?id=187 I have send one packet like that opcode:0x10 key:cachedump10 i get Not Fonud I send another like this opcode:0x10 key:items i got right thing so what should i do ,when i want cachedump 1 0 ?
Re: Issue 187 in memcached: no example for stats cachedump in binary-Protocol
Comment #8 on issue 187 by dsalli...@gmail.com: no example for stats cachedump in binary-Protocol http://code.google.com/p/memcached/issues/detail?id=187 what should i do ,when i want cachedump 1 0 ? Spend some time asking yourself why you are trying to use an undocumented debug interface that we haven't got around to pulling yet. If you need this for any reason other than server development/debugging, you're probably not getting what you want. And if you're doing it for that reason, you should already understand how to use it well enough. Seriously, this isn't a supported interface and is subject to change or removal. If your application relies on it, that's a bug in your application.
Issue 187 in memcached: no example for stats cachedump in binary-Protocol
Status: New Owner: Labels: Type-Defect Priority-Medium New issue 187 by sarow...@gmail.com: no example for stats cachedump in binary-Protocol http://code.google.com/p/memcached/issues/detail?id=187 In memcached Protocol-binary.xml , it has nothing with “stats cachedump ” command， i want add one feature for xmemcached , but i can`t get the right reply . it`s say Not found or Invalid arguments . Can you give me a example with stats cachedump in binary protocol ? What is the expected output? What do you see instead? What version of the product are you using? On what operating system? 1.4.5 Please provide any additional information below. give a example with stats cachedump in binary-Protocol
Re: Issue 187 in memcached: no example for stats cachedump in binary-Protocol
Comment #1 on issue 187 by sarow...@gmail.com: no example for stats cachedump in binary-Protocol http://code.google.com/p/memcached/issues/detail?id=187 in memcached code： typedef protocol_binary_request_no_extras protocol_binary_request_stats; stats request is no extras , where should i add my arguments ? key ? value ?
Re: Reported error in binary protocol test on Solaris since 1.4.4
Hi, On 19 Jan., 23:38, Dagobert honkma...@googlemail.com wrote: I have a strange phenomenon: The test t/binary.t fails from 1.4.4 for me on Solaris 9 Sparc with Sun Studio 12. I nailed it down to this commit causing the failure: https://github.com/memcached/memcached/commit/5100e7af8802b8170adb8a7... These two lines with APPEND_STAT seem to push something over the edge. If I comment these two lines out the test binary.t succeeds. Adding and deleting some of the APPEND_STAT lines breaks the test at different places. With the lines from the commit that is I did some more research and the results are split: 81 10 00 09 00 00 00 00 00 00 00 0a d4 22 ae e8 00 00 00 00 00 00 00 00 81 10 00 00 00 00 00 00 00 00 # Failed test 'Expected read length' # at t/binary.t line 540. # got: '10' # expected: '24' Use of uninitialized value $ident_hi in multiplication (*) at t/ binary.t line 546. Use of uninitialized value $ident_lo in addition (+) at t/binary.t line 546. Use of uninitialized value $remaining in numeric eq (==) at t/binary.t line 548. 00 00 d4 22 ae e8 00 00 00 00 00 00 00 00 # Failed test 'Expected read length' # at t/binary.t line 540. # got: '14' # expected: '24' Best regards -- Dago
Re: Issue 106 in memcached: binary protocol parsing can cause memcached server lockup
Comment #4 on issue 106 by airat.ha...@gmail.com: binary protocol parsing can cause memcached server lockup http://code.google.com/p/memcached/issues/detail?id=106 may be this specific issue is solved by the provided patch (haven't tried), but in general the problem remains. Even after applying the path suggested the following packet sent through udp hangs memcached udp: \x00\x00\x00\x00\x00\x01\x00\x00\x80\x05\x00\x01\x08\x00\x00\x00\x00\x00\x00\x0a\xef\xbe\xad\xde\x00\x00\x00\x00\x00\x00\x00\x00 (in fact any subsequent packet causes 100% usage) Is is a storage_command (in terms of testapp.c), but the cmd (\x05, increment) is of type 'arithmetic_command' (in terms of testapp.c). About this packet - all fields are 'correct' except for the type of cmd. In the attachment - script that reproduces the livelock. Attachments: udp_livelock.py 931 bytes
Issue 176 in memcached: Binary protocol: delete_hits and delete_misses not incremented?
Status: New Owner: Labels: Type-Defect Priority-Medium New issue 176 by evanjelias: Binary protocol: delete_hits and delete_misses not incremented? http://code.google.com/p/memcached/issues/detail?id=176 Hi folks, When using the binary protocol, it seems that the delete_hits and delete_misses stats don't appear to be incremented upon issuing delete commands. I think the culprit is simply that process_bin_delete() is missing the appropriate logic to increment these. So the fix might just involve copying a couple lines from the text protocol's process_delete_command(). Not really a big deal, but it was rather perplexing to see these stats at 0 globally, as well as for every slab class. I'm using memcached 1.4.5, btw. Thanks, Evan Elias
Re: Issue 176 in memcached: Binary protocol: delete_hits and delete_misses not incremented?
Updates: Status: Fixed Comment #1 on issue 176 by dsallings: Binary protocol: delete_hits and delete_misses not incremented? http://code.google.com/p/memcached/issues/detail?id=176 This was fixed in 83af8a219b42e0c46a8a7cfd5def27444c6fe78b (not yet in a release)
Re: Issue 106 in memcached: binary protocol parsing can cause memcached server lockup
Updates: Owner: eric.d.lambert Comment #3 on issue 106 by eric.d.lambert: binary protocol parsing can cause memcached server lockup http://code.google.com/p/memcached/issues/detail?id=106 this looks similar to the problem with issue 158, so i'll take a look at this
Re: Issue 107 in memcached: binary protocol can only parse 1 command within a recieved udp / tcp buffer
Updates: Owner: eric.d.lambert Comment #1 on issue 107 by eric.d.lambert: binary protocol can only parse 1 command within a recieved udp / tcp buffer http://code.google.com/p/memcached/issues/detail?id=107 (No comment was entered for this change.)
Re: Issue 106 in memcached: binary protocol parsing can cause memcached server lockup
Comment #1 on issue 106 by pi3orama: binary protocol parsing can cause memcached server lockup http://code.google.com/p/memcached/issues/detail?id=106 The root cause of this issue is try_read_udp() never reset c-rbytes. The processing of conn_nread minus c-rbytes by c-rlbytes, so if extra bytes exists, they will be 'left' in c-rbytes. However, each time when recvfrom()s UDP socket, the whole read buffer is overwritten, so 'c-rbytes += res' sets c-rbytes incorrectly. After the binary 'GET' command fail, the state of connection is transferred to 'conn_new_cmd' in write_bin_error(), then 'conn_parse_cmd' in reset_cmd_handler(). When c-rbytes less than sizeof(c-binary_header) (24 bytes), the server believes that there's no enough bytes to hold binary header so the processing continues normally. However, in the processing of attached test program, c-rbytes increases by 1 each time a request is completed. Therefore, after 24 requests, server (wrongly) thinks there's an extra binary header, and it finally gets wrong magic in try_read_command(). The dead lock is caused by the error processing code. If the UDP connection is in conn_closing state, it never get closed but only calls conn_cleanup(). Therefore, when there are incoming packets in the udp socket, they will never be consumed, so epoll_wait() (in libevent) triggers input events over and over again for a closing connection. To set c-rbytes correctly: --- ./memcached.ori.c 2010-08-23 22:59:12.0 +0800 +++ ./memcached.c 2010-08-23 22:59:17.0 +0800 @@ -3223,7 +3223,7 @@ res -= 8; memmove(c-rbuf, c-rbuf + 8, res); -c-rbytes += res; +c-rbytes = res; c-rcurr = c-rbuf; return READ_DATA_RECEIVED; } To consume incoming packets when cleanup: --- ./memcached.ori.c 2010-08-23 22:59:12.0 +0800 +++ ./memcached.c 2010-08-23 23:27:38.0 +0800 @@ -471,6 +471,9 @@ sasl_dispose(c-sasl_conn); c-sasl_conn = NULL; } + +/* consume incoming packets */ +recvfrom(c-sfd, NULL, 0, 0, NULL, NULL); } /*
Re: Issue 48 in memcached: binary protocol incr on text returns success 0
Comment #5 on issue 48 by a...@enyim.com: binary protocol incr on text returns success 0 http://code.google.com/p/memcached/issues/detail?id=48 i'm not sure which version includes this fix, but both 1.4.3 and 1.4.4 give me a status code 0 (SUCCESS) when trying to increment non numeric values: (MyKey has the value Hello World) incr MyKey 12, 1, 0 24 Writing an error: Non-numeric server-side value for incr or decr 24 Writing bin response: 24 0x81 0x06 0x00 0x00 24 0x00 0x00 0x00 0x06 24 0x00 0x00 0x00 0x2e 24 0x00 0x00 0x00 0x05 24 0x00 0x00 0x00 0x00 24 0x00 0x00 0x00 0x00 -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings
Re: Issue 48 in memcached: binary protocol incr on text returns success 0
Comment #6 on issue 48 by dsallings: binary protocol incr on text returns success 0 http://code.google.com/p/memcached/issues/detail?id=48 I see status code 6 and the error text there. 6 == bad value for incr/decr. I believe this is correct. This change went in as 1.4.0-rc1-2-gcce46e8 -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings
Re: Issue 48 in memcached: binary protocol incr on text returns success 0
Comment #7 on issue 48 by a...@enyim.com: binary protocol incr on text returns success 0 http://code.google.com/p/memcached/issues/detail?id=48 yeah, sorry i forgot that the status is supposed to be 16bit not 8. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings
Problems with binary protocol and memcached PECL extension
Hi guys,
I posted this to the libmemcached mailing list a while ago and didn't
get a response, but this list is a lot more active so I'm hoping
someone here will have answers for me. :)
I've taken some time to work on porting our code from using the PHP
PECL memcache extension to using the PECL memcached extension so we
can take advantage of all the advanced functionality that libmemcached
has to offer, but I'm running into some issues using the binary
protocol.
Here is my code:
?php
$servers = array(array('localhost', '11211'));
$m = new Memcached();
$m-addServers($servers);
$m-setOption(Memcached::OPT_DISTRIBUTION,
Memcached::DISTRIBUTION_CONSISTENT);
$m-setOption(Memcached::OPT_CONNECT_TIMEOUT, 500);
$m-setOption(Memcached::OPT_SEND_TIMEOUT, 500);
$m-setOption(Memcached::OPT_RECV_TIMEOUT, 500);
$m-setOption(Memcached::OPT_BINARY_PROTOCOL, true);
$m-setOption(Memcached::OPT_SERVER_FAILURE_LIMIT, 1);
$m-set('foo', '100');
var_dump($m-get('foo'));
?
If I run this, the script never finishes executing.
If I change OPT_BINARY_PROTOCOL to false, it instantly returns with
the results.
So the two major issues are that it doesn't seem to be obeying my
timeout settings, and of course the binary protocol doesn't seem to be
working. Is there something I need to change on the server end to
support binary protocol? I'm running version 1.4.4 of memcached and
have the latest libmemcached and PECL memcached extensions installed.
Thanks!
Jay
Re: Problems with binary protocol and memcached PECL extension
does the get or the set hold it up?
Brian.
http://brian.moonspot.net/
On 1/6/10 3:38 PM, Jay Paroline wrote:
Hi guys,
I posted this to the libmemcached mailing list a while ago and didn't
get a response, but this list is a lot more active so I'm hoping
someone here will have answers for me. :)
I've taken some time to work on porting our code from using the PHP
PECL memcache extension to using the PECL memcached extension so we
can take advantage of all the advanced functionality that libmemcached
has to offer, but I'm running into some issues using the binary
protocol.
Here is my code:
?php
$servers = array(array('localhost', '11211'));
$m = new Memcached();
$m-addServers($servers);
$m-setOption(Memcached::OPT_DISTRIBUTION,
Memcached::DISTRIBUTION_CONSISTENT);
$m-setOption(Memcached::OPT_CONNECT_TIMEOUT, 500);
$m-setOption(Memcached::OPT_SEND_TIMEOUT, 500);
$m-setOption(Memcached::OPT_RECV_TIMEOUT, 500);
$m-setOption(Memcached::OPT_BINARY_PROTOCOL, true);
$m-setOption(Memcached::OPT_SERVER_FAILURE_LIMIT, 1);
$m-set('foo', '100');
var_dump($m-get('foo'));
?
If I run this, the script never finishes executing.
If I change OPT_BINARY_PROTOCOL to false, it instantly returns with
the results.
So the two major issues are that it doesn't seem to be obeying my
timeout settings, and of course the binary protocol doesn't seem to be
working. Is there something I need to change on the server end to
support binary protocol? I'm running version 1.4.4 of memcached and
have the latest libmemcached and PECL memcached extensions installed.
Thanks!
Jay
Re: Problems with binary protocol and memcached PECL extension
It looks like both/either. I added print statements in front of each,
and it doesn't get to the get. If I comment out the set, then it hangs
on the get.
Thanks,
Jay
On Jan 6, 4:43 pm, Brian Moon br...@moonspot.net wrote:
does the get or the set hold it up?
Brian.
http://brian.moonspot.net/
On 1/6/10 3:38 PM, Jay Paroline wrote:
Hi guys,
I posted this to the libmemcached mailing list a while ago and didn't
get a response, but this list is a lot more active so I'm hoping
someone here will have answers for me. :)
I've taken some time to work on porting our code from using the PHP
PECL memcache extension to using the PECL memcached extension so we
can take advantage of all the advanced functionality that libmemcached
has to offer, but I'm running into some issues using the binary
protocol.
Here is my code:
?php
$servers = array(array('localhost', '11211'));
$m = new Memcached();
$m-addServers($servers);
$m-setOption(Memcached::OPT_DISTRIBUTION,
Memcached::DISTRIBUTION_CONSISTENT);
$m-setOption(Memcached::OPT_CONNECT_TIMEOUT, 500);
$m-setOption(Memcached::OPT_SEND_TIMEOUT, 500);
$m-setOption(Memcached::OPT_RECV_TIMEOUT, 500);
$m-setOption(Memcached::OPT_BINARY_PROTOCOL, true);
$m-setOption(Memcached::OPT_SERVER_FAILURE_LIMIT, 1);
$m-set('foo', '100');
var_dump($m-get('foo'));
?
If I run this, the script never finishes executing.
If I change OPT_BINARY_PROTOCOL to false, it instantly returns with
the results.
So the two major issues are that it doesn't seem to be obeying my
timeout settings, and of course the binary protocol doesn't seem to be
working. Is there something I need to change on the server end to
support binary protocol? I'm running version 1.4.4 of memcached and
have the latest libmemcached and PECL memcached extensions installed.
Thanks!
Jay
Re: Problems with binary protocol and memcached PECL extension
and what versions of libmemcached and pecl/memcached are you using? php
-i can tell you that.
Brian.
http://brian.moonspot.net/
On 1/6/10 3:45 PM, Jay Paroline wrote:
It looks like both/either. I added print statements in front of each,
and it doesn't get to the get. If I comment out the set, then it hangs
on the get.
Thanks,
Jay
On Jan 6, 4:43 pm, Brian Moonbr...@moonspot.net wrote:
does the get or the set hold it up?
Brian.
http://brian.moonspot.net/
On 1/6/10 3:38 PM, Jay Paroline wrote:
Hi guys,
I posted this to the libmemcached mailing list a while ago and didn't
get a response, but this list is a lot more active so I'm hoping
someone here will have answers for me. :)
I've taken some time to work on porting our code from using the PHP
PECL memcache extension to using the PECL memcached extension so we
can take advantage of all the advanced functionality that libmemcached
has to offer, but I'm running into some issues using the binary
protocol.
Here is my code:
?php
$servers = array(array('localhost', '11211'));
$m = new Memcached();
$m-addServers($servers);
$m-setOption(Memcached::OPT_DISTRIBUTION,
Memcached::DISTRIBUTION_CONSISTENT);
$m-setOption(Memcached::OPT_CONNECT_TIMEOUT, 500);
$m-setOption(Memcached::OPT_SEND_TIMEOUT, 500);
$m-setOption(Memcached::OPT_RECV_TIMEOUT, 500);
$m-setOption(Memcached::OPT_BINARY_PROTOCOL, true);
$m-setOption(Memcached::OPT_SERVER_FAILURE_LIMIT, 1);
$m-set('foo', '100');
var_dump($m-get('foo'));
?
If I run this, the script never finishes executing.
If I change OPT_BINARY_PROTOCOL to false, it instantly returns with
the results.
So the two major issues are that it doesn't seem to be obeying my
timeout settings, and of course the binary protocol doesn't seem to be
working. Is there something I need to change on the server end to
support binary protocol? I'm running version 1.4.4 of memcached and
have the latest libmemcached and PECL memcached extensions installed.
Thanks!
Jay
Re: Problems with binary protocol and memcached PECL extension
What server version are you using?
Trond
On Wednesday, January 6, 2010, Brian Moon br...@moonspot.net wrote:
and what versions of libmemcached and pecl/memcached are you using? php -i
can tell you that.
Brian.
http://brian.moonspot.net/
On 1/6/10 3:45 PM, Jay Paroline wrote:
It looks like both/either. I added print statements in front of each,
and it doesn't get to the get. If I comment out the set, then it hangs
on the get.
Thanks,
Jay
On Jan 6, 4:43 pm, Brian Moonbr...@moonspot.net wrote:
does the get or the set hold it up?
Brian.
http://brian.moonspot.net/
On 1/6/10 3:38 PM, Jay Paroline wrote:
Hi guys,
I posted this to the libmemcached mailing list a while ago and didn't
get a response, but this list is a lot more active so I'm hoping
someone here will have answers for me. :)
I've taken some time to work on porting our code from using the PHP
PECL memcache extension to using the PECL memcached extension so we
can take advantage of all the advanced functionality that libmemcached
has to offer, but I'm running into some issues using the binary
protocol.
Here is my code:
?php
$servers = array(array('localhost', '11211'));
$m = new Memcached();
$m-addServers($servers);
$m-setOption(Memcached::OPT_DISTRIBUTION,
Memcached::DISTRIBUTION_CONSISTENT);
$m-setOption(Memcached::OPT_CONNECT_TIMEOUT, 500);
$m-setOption(Memcached::OPT_SEND_TIMEOUT, 500);
$m-setOption(Memcached::OPT_RECV_TIMEOUT, 500);
$m-setOption(Memcached::OPT_BINARY_PROTOCOL, true);
$m-setOption(Memcached::OPT_SERVER_FAILURE_LIMIT, 1);
$m-set('foo', '100');
var_dump($m-get('foo'));
?
If I run this, the script never finishes executing.
If I change OPT_BINARY_PROTOCOL to false, it instantly returns with
the results.
So the two major issues are that it doesn't seem to be obeying my
timeout settings, and of course the binary protocol doesn't seem to be
working. Is there something I need to change on the server end to
support binary protocol? I'm running version 1.4.4 of memcached and
have the latest libmemcached and PECL memcached extensions installed.
Thanks!
Jay
--
Trond Norbye
Re: Problems with binary protocol and memcached PECL extension
1.4.4
On Jan 6, 5:07 pm, Trond Norbye trond.nor...@gmail.com wrote:
What server version are you using?
Trond
On Wednesday, January 6, 2010, Brian Moon br...@moonspot.net wrote:
and what versions of libmemcached and pecl/memcached are you using? php -i
can tell you that.
Brian.
http://brian.moonspot.net/
On 1/6/10 3:45 PM, Jay Paroline wrote:
It looks like both/either. I added print statements in front of each,
and it doesn't get to the get. If I comment out the set, then it hangs
on the get.
Thanks,
Jay
On Jan 6, 4:43 pm, Brian Moonbr...@moonspot.net wrote:
does the get or the set hold it up?
Brian.
http://brian.moonspot.net/
On 1/6/10 3:38 PM, Jay Paroline wrote:
Hi guys,
I posted this to the libmemcached mailing list a while ago and didn't
get a response, but this list is a lot more active so I'm hoping
someone here will have answers for me. :)
I've taken some time to work on porting our code from using the PHP
PECL memcache extension to using the PECL memcached extension so we
can take advantage of all the advanced functionality that libmemcached
has to offer, but I'm running into some issues using the binary
protocol.
Here is my code:
?php
$servers = array(array('localhost', '11211'));
$m = new Memcached();
$m-addServers($servers);
$m-setOption(Memcached::OPT_DISTRIBUTION,
Memcached::DISTRIBUTION_CONSISTENT);
$m-setOption(Memcached::OPT_CONNECT_TIMEOUT, 500);
$m-setOption(Memcached::OPT_SEND_TIMEOUT, 500);
$m-setOption(Memcached::OPT_RECV_TIMEOUT, 500);
$m-setOption(Memcached::OPT_BINARY_PROTOCOL, true);
$m-setOption(Memcached::OPT_SERVER_FAILURE_LIMIT, 1);
$m-set('foo', '100');
var_dump($m-get('foo'));
?
If I run this, the script never finishes executing.
If I change OPT_BINARY_PROTOCOL to false, it instantly returns with
the results.
So the two major issues are that it doesn't seem to be obeying my
timeout settings, and of course the binary protocol doesn't seem to be
working. Is there something I need to change on the server end to
support binary protocol? I'm running version 1.4.4 of memcached and
have the latest libmemcached and PECL memcached extensions installed.
Thanks!
Jay
--
Trond Norbye
Re: Problems with binary protocol and memcached PECL extension
Try running your server from a console and add -vvv to the command
line. Does ti print out any progress?
On Wednesday, January 6, 2010, Jay Paroline boxmon...@gmail.com wrote:
1.4.4
On Jan 6, 5:07 pm, Trond Norbye trond.nor...@gmail.com wrote:
What server version are you using?
Trond
On Wednesday, January 6, 2010, Brian Moon br...@moonspot.net wrote:
and what versions of libmemcached and pecl/memcached are you using? php
-i can tell you that.
Brian.
http://brian.moonspot.net/
On 1/6/10 3:45 PM, Jay Paroline wrote:
It looks like both/either. I added print statements in front of each,
and it doesn't get to the get. If I comment out the set, then it hangs
on the get.
Thanks,
Jay
On Jan 6, 4:43 pm, Brian Moonbr...@moonspot.net wrote:
does the get or the set hold it up?
Brian.
http://brian.moonspot.net/
On 1/6/10 3:38 PM, Jay Paroline wrote:
Hi guys,
I posted this to the libmemcached mailing list a while ago and didn't
get a response, but this list is a lot more active so I'm hoping
someone here will have answers for me. :)
I've taken some time to work on porting our code from using the PHP
PECL memcache extension to using the PECL memcached extension so we
can take advantage of all the advanced functionality that libmemcached
has to offer, but I'm running into some issues using the binary
protocol.
Here is my code:
?php
$servers = array(array('localhost', '11211'));
$m = new Memcached();
$m-addServers($servers);
$m-setOption(Memcached::OPT_DISTRIBUTION,
Memcached::DISTRIBUTION_CONSISTENT);
$m-setOption(Memcached::OPT_CONNECT_TIMEOUT, 500);
$m-setOption(Memcached::OPT_SEND_TIMEOUT, 500);
$m-setOption(Memcached::OPT_RECV_TIMEOUT, 500);
$m-setOption(Memcached::OPT_BINARY_PROTOCOL, true);
$m-setOption(Memcached::OPT_SERVER_FAILURE_LIMIT, 1);
$m-set('foo', '100');
var_dump($m-get('foo'));
?
If I run this, the script never finishes executing.
If I change OPT_BINARY_PROTOCOL to false, it instantly returns with
the results.
So the two major issues are that it doesn't seem to be obeying my
timeout settings, and of course the binary protocol doesn't seem to be
working. Is there something I need to change on the server end to
support binary protocol? I'm running version 1.4.4 of memcached and
have the latest libmemcached and PECL memcached extensions installed.
Thanks!
Jay
--
Trond Norbye
--
Trond Norbye
Re: Problems with binary protocol and memcached PECL extension
This is very odd. If I run it from the command line (with or without
vv) it works as expected. If it starts from init.d it doesn't work.
[r...@rhd011 test]# /etc/init.d/memcached start
Starting memcached:[ OK ]
[r...@rhd011 test]# ps aux | grep memcached
101 29441 0.0 0.0 52448 1008 ?Ssl 20:07 0:00
memcached -d -p 11211 -u memcached -m 64 -c 1024 -P /var/run/memcached/
memcached.pid
^^the above does not work
[r...@rhd011 test]# /etc/init.d/memcached stop
Stopping memcached:[ OK ]
[r...@rhd011 test]# memcached -d -p 11211 -u memcached -m 64 -c 1024 -
P /var/run/memcached/memcached.pid
[r...@rhd011 test]# ps aux | grep memcached
101 29473 0.0 0.0 128064 996 ?Ssl 20:09 0:00
memcached -d -p 11211 -u memcached -m 64 -c 1024 -P /var/run/memcached/
memcached.pid
^^the above works
What the heck is the difference?
Jay
On Jan 6, 5:15 pm, Trond Norbye trond.nor...@gmail.com wrote:
Try running your server from a console and add -vvv to the command
line. Does ti print out any progress?
On Wednesday, January 6, 2010, Jay Paroline boxmon...@gmail.com wrote:
1.4.4
On Jan 6, 5:07 pm, Trond Norbye trond.nor...@gmail.com wrote:
What server version are you using?
Trond
On Wednesday, January 6, 2010, Brian Moon br...@moonspot.net wrote:
and what versions of libmemcached and pecl/memcached are you using? php
-i can tell you that.
Brian.
http://brian.moonspot.net/
On 1/6/10 3:45 PM, Jay Paroline wrote:
It looks like both/either. I added print statements in front of each,
and it doesn't get to the get. If I comment out the set, then it hangs
on the get.
Thanks,
Jay
On Jan 6, 4:43 pm, Brian Moonbr...@moonspot.net wrote:
does the get or the set hold it up?
Brian.
http://brian.moonspot.net/
On 1/6/10 3:38 PM, Jay Paroline wrote:
Hi guys,
I posted this to the libmemcached mailing list a while ago and didn't
get a response, but this list is a lot more active so I'm hoping
someone here will have answers for me. :)
I've taken some time to work on porting our code from using the PHP
PECL memcache extension to using the PECL memcached extension so we
can take advantage of all the advanced functionality that libmemcached
has to offer, but I'm running into some issues using the binary
protocol.
Here is my code:
?php
$servers = array(array('localhost', '11211'));
$m = new Memcached();
$m-addServers($servers);
$m-setOption(Memcached::OPT_DISTRIBUTION,
Memcached::DISTRIBUTION_CONSISTENT);
$m-setOption(Memcached::OPT_CONNECT_TIMEOUT, 500);
$m-setOption(Memcached::OPT_SEND_TIMEOUT, 500);
$m-setOption(Memcached::OPT_RECV_TIMEOUT, 500);
$m-setOption(Memcached::OPT_BINARY_PROTOCOL, true);
$m-setOption(Memcached::OPT_SERVER_FAILURE_LIMIT, 1);
$m-set('foo', '100');
var_dump($m-get('foo'));
?
If I run this, the script never finishes executing.
If I change OPT_BINARY_PROTOCOL to false, it instantly returns with
the results.
So the two major issues are that it doesn't seem to be obeying my
timeout settings, and of course the binary protocol doesn't seem to be
working. Is there something I need to change on the server end to
support binary protocol? I'm running version 1.4.4 of memcached and
have the latest libmemcached and PECL memcached extensions installed.
Thanks!
Jay
--
Trond Norbye
--
Trond Norbye
Re: Problems with binary protocol and memcached PECL extension
Ok, I'm officially semi-retarded. Apparently when I did a make install
of the latest version of memcached on our dev server it installed in /
usr/local/bin but the old version was still in /usr/bin -- when I ran
the daemon it ran from /usr/local/bin but the init.d script was
running it from /usr/bin
I made a sym link from /usr/bin to /usr/local/bin and restarted, and
it works like magic.
Jay
On Jan 6, 8:11 pm, Jay Paroline boxmon...@gmail.com wrote:
This is very odd. If I run it from the command line (with or without
vv) it works as expected. If it starts from init.d it doesn't work.
[r...@rhd011 test]# /etc/init.d/memcached start
Starting memcached: [ OK ]
[r...@rhd011 test]# ps aux | grep memcached
101 29441 0.0 0.0 52448 1008 ? Ssl 20:07 0:00
memcached -d -p 11211 -u memcached -m 64 -c 1024 -P /var/run/memcached/
memcached.pid
^^the above does not work
[r...@rhd011 test]# /etc/init.d/memcached stop
Stopping memcached: [ OK ]
[r...@rhd011 test]# memcached -d -p 11211 -u memcached -m 64 -c 1024 -
P /var/run/memcached/memcached.pid
[r...@rhd011 test]# ps aux | grep memcached
101 29473 0.0 0.0 128064 996 ? Ssl 20:09 0:00
memcached -d -p 11211 -u memcached -m 64 -c 1024 -P /var/run/memcached/
memcached.pid
^^the above works
What the heck is the difference?
Jay
On Jan 6, 5:15 pm, Trond Norbye trond.nor...@gmail.com wrote:
Try running your server from a console and add -vvv to the command
line. Does ti print out any progress?
On Wednesday, January 6, 2010, Jay Paroline boxmon...@gmail.com wrote:
1.4.4
On Jan 6, 5:07 pm, Trond Norbye trond.nor...@gmail.com wrote:
What server version are you using?
Trond
On Wednesday, January 6, 2010, Brian Moon br...@moonspot.net wrote:
and what versions of libmemcached and pecl/memcached are you using?
php -i can tell you that.
Brian.
http://brian.moonspot.net/
On 1/6/10 3:45 PM, Jay Paroline wrote:
It looks like both/either. I added print statements in front of each,
and it doesn't get to the get. If I comment out the set, then it hangs
on the get.
Thanks,
Jay
On Jan 6, 4:43 pm, Brian Moonbr...@moonspot.net wrote:
does the get or the set hold it up?
Brian.
http://brian.moonspot.net/
On 1/6/10 3:38 PM, Jay Paroline wrote:
Hi guys,
I posted this to the libmemcached mailing list a while ago and didn't
get a response, but this list is a lot more active so I'm hoping
someone here will have answers for me. :)
I've taken some time to work on porting our code from using the PHP
PECL memcache extension to using the PECL memcached extension so we
can take advantage of all the advanced functionality that libmemcached
has to offer, but I'm running into some issues using the binary
protocol.
Here is my code:
?php
$servers = array(array('localhost', '11211'));
$m = new Memcached();
$m-addServers($servers);
$m-setOption(Memcached::OPT_DISTRIBUTION,
Memcached::DISTRIBUTION_CONSISTENT);
$m-setOption(Memcached::OPT_CONNECT_TIMEOUT, 500);
$m-setOption(Memcached::OPT_SEND_TIMEOUT, 500);
$m-setOption(Memcached::OPT_RECV_TIMEOUT, 500);
$m-setOption(Memcached::OPT_BINARY_PROTOCOL, true);
$m-setOption(Memcached::OPT_SERVER_FAILURE_LIMIT, 1);
$m-set('foo', '100');
var_dump($m-get('foo'));
?
If I run this, the script never finishes executing.
If I change OPT_BINARY_PROTOCOL to false, it instantly returns with
the results.
So the two major issues are that it doesn't seem to be obeying my
timeout settings, and of course the binary protocol doesn't seem to be
working. Is there something I need to change on the server end to
support binary protocol? I'm running version 1.4.4 of memcached and
have the latest libmemcached and PECL memcached extensions installed.
Thanks!
Jay
--
Trond Norbye
--
Trond Norbye
Issue 3 in memcached: Textual delete command w/ expire time noreply in binary protocol version
Comment #4 on issue 3 by dsallings: Textual delete command w/ expire time noreply in binary protocol version http://code.google.com/p/memcached/issues/detail?id=3 I've pushed a branch for this (finally... this is an old one). -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings
Issue 3 in memcached: Textual delete command w/ expire time noreply in binary protocol version
Updates: Status: Fixed Comment #7 on issue 3 by trond.norbye: Textual delete command w/ expire time noreply in binary protocol version http://code.google.com/p/memcached/issues/detail?id=3 (No comment was entered for this change.) -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings
Issue with binary protocol spec GET response and key field
Hello, I am working through writing a simple Java UDP client; apparently none of the clients already written support UDP, sigh. The example response in the GET section of the binary protocol shows Key as None, meaning it is omitted in the response. Field(offset) (value) Magic(0): 0x81 Opcode (1): 0x00 Key length (2,3) : 0x Extra length (4): 0x04 Data type(5): 0x00 Status (6,7) : 0x Total body (8-11) : 0x0009 Opaque (12-15): 0x CAS (16-23): 0x0001 Extras : Flags (24-27): 0xdeadbeef Key : None Value(28-32): The textual string World However, in the prior section it states: Response (if found): MUST have extras. MAY have key. MAY have value. Under which conditions will the key be present? Under which conditions will it not. Can someone clarify this in the spec and in this forum? Thank you, Bob
Re: Issue with binary protocol spec GET response and key field
On Oct 22, 1:24 pm, Robert Buck buck.rober...@gmail.com wrote: However, in the prior section it states: Response (if found): MUST have extras. MAY have key. MAY have value. Under which conditions will the key be present? Under which conditions will it not. Can someone clarify this in the spec and in this forum? A GET/GETQ command will not have a key, but there's a GETK/GETKQ command that is exactly like GET/GETQ, but has a key. I'll add to my notes for things to clarify in there when I get back around to documenting protocol (which should be fairly soon, hopefully answering the questions is good enough for now).
Re: Issue with binary protocol spec GET response and key field
Thank you Dustin. On Thu, Oct 22, 2009 at 4:36 PM, Dustin dsalli...@gmail.com wrote: On Oct 22, 1:24 pm, Robert Buck buck.rober...@gmail.com wrote: However, in the prior section it states: Response (if found): MUST have extras. MAY have key. MAY have value. Under which conditions will the key be present? Under which conditions will it not. Can someone clarify this in the spec and in this forum? A GET/GETQ command will not have a key, but there's a GETK/GETKQ command that is exactly like GET/GETQ, but has a key. I'll add to my notes for things to clarify in there when I get back around to documenting protocol (which should be fairly soon, hopefully answering the questions is good enough for now).
memcached FAQ links to obsolete binary protocol doc
The memcached FAQ links to this document describing the binary protocol: http://code.google.com/p/memcached/wiki/MemcacheBinaryProtocol Unfortunately, this document is out of date compared to the protocol-binary.xml that ships with 1.4.0. For example, it is missing various opcodes like IncrementQ. Now that 1.4.0 is out, it would be good to update the protocol document on the wiki. -Mat
Re: memcached FAQ links to obsolete binary protocol doc
On Aug 3, 7:37 pm, Mat Hostetter mjhostet...@gmail.com wrote: The memcached FAQ links to this document describing the binary protocol: http://code.google.com/p/memcached/wiki/MemcacheBinaryProtocol Unfortunately, this document is out of date compared to the protocol-binary.xml that ships with 1.4.0. For example, it is missing various opcodes like IncrementQ. Now that 1.4.0 is out, it would be good to update the protocol document on the wiki. Thanks, I updated the doc.
Binary protocol deficiency in dealing with incr validation (issue 48)
Issue 48 demonstrates that we don't check delta status from within binary incr calls. I've written tests for both incr and decr to show the problem, but I don't have a way to report the error. Currently, I'm using einval, but that's just kind of wrong since that's more to do with the input than the server-side state. Does anyone have any suggestions for better error reporting here? It's a bit of a corner case, but it would actually simplify things considerably as we currently have no easy way to provide varying response messages by error code type. What is definitely wrong is sending down EINVAL with Invalid arguments as the error message.
