Key Size

Marc Marc at facebook.com
Fri Jan 5 19:31:55 UTC 2007


I misspoke about whitespace...the server will drop it, not the client.


On 1/5/07 11:25 AM, "Marc" <Marc at facebook.com> wrote:

> I see two possible problems.  First ­ as you note ­ the client needs to deal
> with the increase too.  I¹m not sure which one you¹re using but for most
> implementations, the default read -buf  size for GET results is 250+1 so, if
> memcached is returning results like:
>     VALUE very<250>long_key 0 3\r\nxxx\r\nEND
> It very well may be the case that the client punts after scanning ³VALUE
> very<250>² without seeing either space (\b) or CRLF (\r\n)
> 
> Second, if you have spaces in your URL this will cause similar problems.  The
> client will take the following:
>     VALUE http://url/key/with white space 0 3\r\nxxx\r\nEND
> 
> as the value for key ³http://url/key/with² and not finding a corresponding
> client request for that key will  most likely discard it.
> 
> On 1/5/07 11:08 AM, "Renato Silveira" <renatosilveira at gmail.com> wrote:
> 
>> Hi,
>> 
>> I´m using memcached as a URL keyword cache. The url is the key and the cached
>> object is a string with relevant keywords of the site. Well, it´s working
>> fine for my purpose. The only problem is the limit of key size to 250
>> bytes(because there can be url bigger than 250 bytes). Well, I tried to
>> increase the value of the constant KEY_MAX_LENGTH to 2048 bytes. I recompile
>> memcached and it´s not working. Should I have to make any modification on the
>> client API? Does anyone can helpme with this issue?
>> 
>> tks!
>> 
>> Renato
>> 
> 
> 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.danga.com/pipermail/memcached/attachments/20070105/cc9d8ede/attachment.html


More information about the memcached mailing list