atom feed6 messages in com.googlegroups.memcachedRe: client behavior with large sizes
FromSent OnAttachments
Matt IngenthronApr 25, 2011 9:48 am 
Matt SellarsApr 28, 2011 6:29 pm 
DustinApr 28, 2011 8:49 pm 
Matt SellarsApr 28, 2011 10:16 pm 
Matt IngenthronApr 28, 2011 10:51 pm 
Matt SellarsApr 29, 2011 6:19 am 
Subject:Re: client behavior with large sizes
From:Matt Sellars (ibbu@gmail.com)
Date:Apr 28, 2011 6:29:47 pm
List:com.googlegroups.memcached

Is the maximum check necessary?

Since the size limitation ultimately resides in the cache implementation storage(Membase, Memcached, specially compiled Memcached, etc) this should at least be configurable with a system property if it has to exist. I'm not sure the max enforcement is needed though. If you are considering raising it for Membase support you're not properly enforcing it for Memcached so why bother at all?

Matt

On Apr 25, 11:48 am, Matt Ingenthron <inge@cep.net> wrote:

Hi,

I'd recently been trying to fix an issue with spymemcached when the server side allows larger than 1MiB.  I'm fairly certain that other clients may have similar issues, so I wanted to kind of collect how clients should behave in this area.

With the change to allow max item size to be a parameter, clients SHOULD NOT assume a maximum size of 1MiB.  Clients SHOULD allow the maximum size they enforce to be configurable.

That said, clients MAY want to have some default maximum size.  Perhaps this size is the existing 1MiB, but it could be something like 20MiB. It should always be possible to override it with configuration.

Optionally, a client COULD (generally one that keeps long lived connections) get item_size_max from "stats settings" to set it's max_item_size.  Even though it probably won't work, this SHOULD be able to be overridden by client configuration.

Obviously, the server should always enforce whatever limit it's configured for by either returning an error or dropping an offending connection.

Any thoughts?