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