Another Delete Question...

[Wayne Hineman]

Hi,
As a newbie to memcached, I've been reading carefully the protocol
document and have a question about the optional time value on the
'delete' command. The document describes very well how it works;
my question is what is the use case for this function? Is it used
widely? I can kind of understand a desire to prevent certain keys
from being stored, but the 'set' command overrides this behavior.
Is it expected that new keys are always 'add'ed and existing keys
always 'replace'd? I might expect that the opposite is true: that
'set' is used more frequently than add/replace, thus making the
optional time on 'delete' moot. So what's the thought behind this
feature?

Thanks!

Wayne



     

[Dormando]

I'm actually a bit curious on this myself, and believe some of the
development work going on has removed this feature, since it is pretty
awkward.

We were discussing it in irc and couldn't find a usage pattern that
isn't better off using 'add' with a low timeout. The way it's
implemented is a dynamic array loop thing, which isn't exactly ideal
anymore.

So, anyone using it? I hope you're listening and speak up soon :) We'll
make a lot more noise as this feature is .. presently slated for removal
I guess.

-Dormando

Wayne Hineman wrote:

> Hi,
> As a newbie to memcached, I've been reading carefully the protocol
> document and have a question about the optional time value on the
> 'delete' command. The document describes very well how it works;
> my question is what is the use case for this function? Is it used
> widely? I can kind of understand a desire to prevent certain keys
> from being stored, but the 'set' command overrides this behavior.
> Is it expected that new keys are always 'add'ed and existing keys
> always 'replace'd? I might expect that the opposite is true: that
> 'set' is used more frequently than add/replace, thus making the
> optional time on 'delete' moot. So what's the thought behind this
> feature?
>
> Thanks!
>
> Wayne
>
>
>
>      

[Josef Finsel]

Dormando,

Delete isn't anything I use in production but it can be very handy to remove keys from the server so I can see how software will react in trying to reload the memcached server. There are other ways I could probably achieve it but this is the most effective for testing.

Josef

"If you see a whole thing - it seems that it's always beautiful. Planets, lives... But up close a world's all dirt and rocks. And day to day, life's a hard job, you get tired, you lose the pattern."
Ursula K. Le Guin

On Wed, Jun 25, 2008 at 2:00 AM, dormando <dormando@...> wrote:

I'm actually a bit curious on this myself, and believe some of the
development work going on has removed this feature, since it is pretty
awkward.

We were discussing it in irc and couldn't find a usage pattern that
isn't better off using 'add' with a low timeout. The way it's
implemented is a dynamic array loop thing, which isn't exactly ideal
anymore.

So, anyone using it? I hope you're listening and speak up soon :) We'll
make a lot more noise as this feature is .. presently slated for removal
I guess.

-Dormando

Wayne Hineman wrote:
> Hi,
> As a newbie to memcached, I've been reading carefully the protocol
> document and have a question about the optional time value on the
> 'delete' command. The document describes very well how it works;
> my question is what is the use case for this function? Is it used
> widely? I can kind of understand a desire to prevent certain keys
> from being stored, but the 'set' command overrides this behavior.
> Is it expected that new keys are always 'add'ed and existing keys
> always 'replace'd? I might expect that the opposite is true: that
> 'set' is used more frequently than add/replace, thus making the
> optional time on 'delete' moot. So what's the thought behind this
> feature?
>
> Thanks!
>
> Wayne
>
>
>
>

[Dustin Sallings]

On Jun 25, 2008, at 1:47, Josef Finsel wrote:

Delete isn't anything I use in production but it can be very handy to remove keys from the server so I can see how software will react in trying to reload the memcached server. There are other ways I could probably achieve it but this is the most effective for testing.

I don't think it's delete itself, but the delete-with-parameter that has somewhat confusing behavior.  Delete itself is surely widely used as it's often far easier to just invalidate a cache than it is to update it.

I use it in my unit tests to make sure my client's implementation causes the server to do what the client expects it to do.   If the client shouldn't expect it anymore, I'd happily kill it off.

-- 

Dustin Sallings

[Josef Finsel]

That's what I get for responding before sunup in the summer when I'm not awake....

You're right, that's one of those options that doesn't make sense.

"If you see a whole thing - it seems that it's always beautiful. Planets, lives... But up close a world's all dirt and rocks. And day to day, life's a hard job, you get tired, you lose the pattern."
Ursula K. Le Guin

On Wed, Jun 25, 2008 at 5:04 AM, Dustin Sallings <dustin@...> wrote:

On Jun 25, 2008, at 1:47, Josef Finsel wrote:

Delete isn't anything I use in production but it can be very handy to remove keys from the server so I can see how software will react in trying to reload the memcached server. There are other ways I could probably achieve it but this is the most effective for testing.

I don't think it's delete itself, but the delete-with-parameter that has somewhat confusing behavior.  Delete itself is surely widely used as it's often far easier to just invalidate a cache than it is to update it.

I use it in my unit tests to make sure my client's implementation causes the server to do what the client expects it to do.   If the client shouldn't expect it anymore, I'd happily kill it off.

-- 

Dustin Sallings

[Brad Fitzpatrick]

So, the original motivation iirc was for people to be able to a little more safely populate memcache (with "add") when reading from an asynchronously replicated slave database.

The pattern would be like:

Updater process:
  delete from memcache with delete-lock + 5 seconds
  delete from masterdb

Reader process:
  read from memcache
    .. miss
  read from (slave) database
  find something in the slave (it hasn't got the delete yet)
  put it in memcache
    .. but get denied

In practice, though, it's a lame strategy.  You don't know at delete time how far behind your slaves "should" be.  And you should never update your memcached sourced from an inconsistent replica.

In my recent memcache hacking I implemented this feature not as memcached.cc does (with the delete queue and timers and such) but rather just reusing the expiration time field to then mean the "delete locked until" field, and using a different internal flags.  You might want to take that approach to remove some complexity while remaining compatible with the docs.

Or just remove it.  I don't think anybody would care.

On Tue, Jun 24, 2008 at 11:00 PM, dormando <dormando@...> wrote:

I'm actually a bit curious on this myself, and believe some of the
development work going on has removed this feature, since it is pretty
awkward.

We were discussing it in irc and couldn't find a usage pattern that
isn't better off using 'add' with a low timeout. The way it's
implemented is a dynamic array loop thing, which isn't exactly ideal
anymore.

So, anyone using it? I hope you're listening and speak up soon :) We'll
make a lot more noise as this feature is .. presently slated for removal
I guess.

-Dormando

Wayne Hineman wrote:
> Hi,
> As a newbie to memcached, I've been reading carefully the protocol
> document and have a question about the optional time value on the
> 'delete' command. The document describes very well how it works;
> my question is what is the use case for this function? Is it used
> widely? I can kind of understand a desire to prevent certain keys
> from being stored, but the 'set' command overrides this behavior.
> Is it expected that new keys are always 'add'ed and existing keys
> always 'replace'd? I might expect that the opposite is true: that
> 'set' is used more frequently than add/replace, thus making the
> optional time on 'delete' moot. So what's the thought behind this
> feature?
>
> Thanks!
>
> Wayne
>
>
>
>

[Dormando]

I think we'll slate it for removal, but change the implementation if
someone speaks up during the -rc process. This feature confuses a lot of
people already.

Thanks though, I couldn't find the original mails :)

Brad Fitzpatrick wrote:

> So, the original motivation iirc was for people to be able to a little
> more safely populate memcache (with "add") when reading from an
> asynchronously replicated slave database.
>
> The pattern would be like:
>
> Updater process:
>   delete from memcache with delete-lock + 5 seconds
>   delete from masterdb
>
> Reader process:
>   read from memcache
>     .. miss
>   read from (slave) database
>   find something in the slave (it hasn't got the delete yet)
>   put it in memcache
>     .. but get denied
>
> In practice, though, it's a lame strategy.  You don't know at delete
> time how far behind your slaves "should" be.  And you should never
> update your memcached sourced from an inconsistent replica.
>
> In my recent memcache hacking I implemented this feature not as
> memcached.cc does (with the delete queue and timers and such) but rather
> just reusing the expiration time field to then mean the "delete locked
> until" field, and using a different internal flags.  You might want to
> take that approach to remove some complexity while remaining compatible
> with the docs.
>
> Or just remove it.  I don't think anybody would care.
>
>
> On Tue, Jun 24, 2008 at 11:00 PM, dormando <dormando@...
> <mailto:dormando@...>> wrote:
>
>     I'm actually a bit curious on this myself, and believe some of the
>     development work going on has removed this feature, since it is pretty
>     awkward.
>
>     We were discussing it in irc and couldn't find a usage pattern that
>     isn't better off using 'add' with a low timeout. The way it's
>     implemented is a dynamic array loop thing, which isn't exactly ideal
>     anymore.
>
>     So, anyone using it? I hope you're listening and speak up soon :) We'll
>     make a lot more noise as this feature is .. presently slated for removal
>     I guess.
>
>     -Dormando
>
>     Wayne Hineman wrote:
>      > Hi,
>      > As a newbie to memcached, I've been reading carefully the protocol
>      > document and have a question about the optional time value on the
>      > 'delete' command. The document describes very well how it works;
>      > my question is what is the use case for this function? Is it used
>      > widely? I can kind of understand a desire to prevent certain keys
>      > from being stored, but the 'set' command overrides this behavior.
>      > Is it expected that new keys are always 'add'ed and existing keys
>      > always 'replace'd? I might expect that the opposite is true: that
>      > 'set' is used more frequently than add/replace, thus making the
>      > optional time on 'delete' moot. So what's the thought behind this
>      > feature?
>      >
>      > Thanks!
>      >
>      > Wayne
>      >
>      >
>      >
>      >
>
>