Jdesk / memcached

Automatically exported from code.google.com/p/memcached
0 stars 0 forks source link

no example for "stats cachedump" in binary-Protocol #187

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
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 

Original issue reported on code.google.com by sarow...@gmail.com on 23 Feb 2011 at 12:44

GoogleCodeExporter commented 9 years ago
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 ?

Original comment by sarow...@gmail.com on 23 Feb 2011 at 3:04

GoogleCodeExporter commented 9 years ago
You should use the key field, but I don't think memcached 1.4.5 supports stats 
cachedump in the binary protocol

Original comment by trond.no...@gmail.com on 23 Feb 2011 at 8:44

GoogleCodeExporter commented 9 years ago
"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 . 

Original comment by sarow...@gmail.com on 23 Feb 2011 at 9:03

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
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.  :)

Original comment by dsalli...@gmail.com on 23 Feb 2011 at 9:29

GoogleCodeExporter commented 9 years ago
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

Original comment by sarow...@gmail.com on 24 Feb 2011 at 1:24

GoogleCodeExporter commented 9 years ago
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 ?

Original comment by sarow...@gmail.com on 24 Feb 2011 at 1:43

GoogleCodeExporter commented 9 years ago
> 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.

Original comment by dsalli...@gmail.com on 24 Feb 2011 at 4:51

GoogleCodeExporter commented 9 years ago
ok i got it , thank you .

Original comment by sarow...@gmail.com on 24 Feb 2011 at 8:27