search

stevenkang / spymemcached

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

getstats() not working properly (at least against Membase) #156

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
Hi Tim,

On 11/8/10 10:21 AM, Tim Sneed wrote:
> Hey ladies and gents, I am in the mist of using your incredible
> memcached client to execute "stats" commands against a membase node. I
> know that it's not fully supported, but I was hoping to write my own
> parser for the proxy stats, and possibly all of membase's extended
> stat options (all, dispatcher, hash, tap, timings, vkey, and reset).

It should be supported, actually.  The individual stat replies come back
as keys and values, but things are intended to work with the getStats()
method with an argument.  You've found a case where things aren't
behaving well though.

> An idea of the syntax of these "proxy" stats looks like this:
>
>
> 2010-11-08 13:15:06,656|DEBUG|StatsOperationImpl|Got Line: STAT
> memcached:stats:threads 5
> 2010-11-08 13:15:06,656|DEBUG|StatsOperationImpl|Got Line: STAT
> memcached:stats:conn_yields 72
> 2010-11-08 13:15:06,671|DEBUG|StatsOperationImpl|Got Line: STAT
> proxy_main:conf_type dynamic
> 2010-11-08 13:15:06,671|DEBUG|StatsOperationImpl|Got Line: STAT
> proxy_main:behavior:cycle 0
> 2010-11-08 13:15:06,671|DEBUG|StatsOperationImpl|Got Line: STAT
> proxy_main:behavior:downstream_max 4
> 2010-11-08 13:15:06,671|DEBUG|StatsOperationImpl|Got Line: STAT
> proxy_main:behavior:downstream_conn_max 0
> 2010-11-08 13:15:06,671|DEBUG|StatsOperationImpl|Got Line: STAT
> proxy_main:behavior:downstream_weight 0
> 2010-11-08 13:15:06,671|DEBUG|StatsOperationImpl|Got Line: STAT
> proxy_main:behavior:downstream_retry 1
> 2010-11-08 13:15:06,671|DEBUG|StatsOperationImpl|Got Line: STAT
> proxy_main:behavior:downstream_protocol 8
>
> So you can see the current parser of just assuming there are two
> spaces in between the processing line (for example: "STAT version
> 1.4.5") just will not work. While it won't be very hard to make a
> custom parser for both the binary and ascii protocol impls; the binary
> protocol impl method StatsOperationImpl.finishedPayload(byte[] pl) is
> never even called when I execute mc.getStats("proxy"), only for the
> standard getStats() with no arguments).
>
> Is there some sort of check to ensure the format of the returned lines
> are consistent with what's expected before handing it over to
> finishedPayload(byte[] pl)? With the callbacks, it's not very easy for
> me to debug (I'm still a learning java programmer).

I've not looked that closely at it yet, but I think we need to fix the
StatsOperationImpl for both ascii and binary.  Having just looked over
the protocol.txt, the stats from moxi appear to be well formed, so spy
is just making erroneous assumptions about protocol in both the ascii
and binary implementations.  For instance:

            String[] parts=line.split(" ", 3);
            assert parts.length == 3;
            cb.gotStat(parts[1], parts[2]);

https://github.com/dustin/java-memcached-client/blob/master/src/main/java/net/sp
y/memcached/protocol/ascii/StatsOperationImpl.java#L40

(I've not looked at binary yet, but will probably find something similar).

I think rather than a custom parser, we should just fix the parser. 
Oddly, it looks like the assertion used to handle more than three tokens
when split on a space, but it still never really did the right thing,
since it would assume the value could not have a space.

- Matt

Original issue reported on code.google.com by perryk...@gmail.com on 10 Nov 2010 at 11:04

GoogleCodeExporter commented 9 years ago

Original comment by ingen...@gmail.com on 18 Feb 2011 at 7:09

GoogleCodeExporter commented 9 years ago

Original comment by ingen...@gmail.com on 8 Jun 2011 at 10:51

GoogleCodeExporter commented 9 years ago

Original comment by ingen...@gmail.com on 23 Aug 2011 at 3:39

GoogleCodeExporter commented 9 years ago 
Fixed for the ascii protocol. Looks like stats proxy isn't supported in the 
binary protocol.

Original comment by mikewie...@gmail.com on 7 Oct 2011 at 10:13

GoogleCodeExporter commented 9 years ago 
Just to be clear, this issue may actually be a protocol violation.  We're 
looking into it.

Original comment by ingen...@gmail.com on 7 Oct 2011 at 10:38

GoogleCodeExporter commented 9 years ago 
@perry 
After all, we've decided this is a protocol violation.  There will be an issue 
filed against moxi to fix the issue there.  Sorry for the length of time it's 
taken to get this addressed.

Please re-post if you have any other questions.

Original comment by ingen...@gmail.com on 12 Oct 2011 at 11:00