Some debugging code

[Randy Wigginton]

Marc,
I started off looking at doing exactly what you suggest, and realized  
that the order of items can change pretty quickly as things expire  
and get added.  This code works because it is a snapshot; nothing can  
change while the table is being walked.

On Oct 31, 2006, at 5:03 PM, Marc Kwiatkowski wrote:

> The problem with this is that it assumes exactly how item**  
> hashtable is implemented.  Given recent changes to assoc.c to  
> resize the hashtable dynamically, this code would break.  I’d like  
> to see the assoc.c API become more opaque not less.
>
> What might solve the problem is a NEXT command, ie;
>
>     next <key>\r\n
>     =>
>     value <key> <f> <exptime>\r\n<value>\r\nnext <next-key>\r\nend\r\n
>
> Where next key is the “next” key after the current one by whatever  
> rules assoc.c::hashtable decides.  To implement this, one would add  
> assoc.c::assoc_find_next to get the next key given the current  
> one.  Something like that seems to me suitable to left around in  
> production code.
>
>
> On 10/31/06 8:54 AM, "Randy Wigginton" <krw at nobugz.com> wrote:
>
>>
>> Many times someone has asked this list "How can I see all the keys  
>> in my memcache server?", and the response is always, "You can't,  
>> that isn't the point, etc."  First, in general I agree that  
>> memcache operations need to be extremely fast and not run the risk  
>> of tying up the server for any length of time.  However, when  
>> debugging, I am not hitting the server very hard, and I've  
>> encountered numerous times when I needed to find out what was in  
>> the server.  So, if you need to see what your server knows about,  
>> you can add this code into the main command handler in  
>> memcached.c, and then you will be able to send the "keys" command  
>> to get a listing of all keys in that server.
>>
>> This may not help anyone,and this is not recommended to be used in  
>> a high-volume production server.  YMMV.  First, add the following  
>> line to assoc.c:
>> item ** getHashtable() { return hashtable; }
>>
>> Then add this code to memcached.c, its pretty obvious where it  
>> belongs.
>>
>>     if (strcmp(command, "keys") == 0) {
>>         extern item** getHashtable();
>>         item **hashtable = getHashtable();
>>         unsigned long i;
>>         for (i=0; i<1<<20/*HASHPOWER*/; i++) {
>>             item *it = hashtable[i];
>> int outOfMem = 0;
>>             while (it && !outOfMem) {
>>                 char *key = ITEM_key(it);
>> outOfMem = add_iov(c, key, strlen(key));
>> outOfMem += add_iov(c, "\r\n", 2);
>>                 it = it->h_next;
>>             }
>>         }
>>         add_iov(c, "END\r\n", 5);
>>
>> conn_set_state(c, conn_write);
>> c->write_and_go = conn_read;
>> return;
>>     }
>>
>> Since this code is NOT a part of the true memcache release, and  
>> has not been tested, please be cautious with this.  Good debugging!
>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.danga.com/pipermail/memcached/attachments/20061031/eab8ac95/attachment.htm