dustin at spy.net
Thu Sep 6 05:30:33 UTC 2007
On Sep 5, 2007, at 19:04, Aaron Stone wrote:
> I have thought about doing this, too -- the issues I'm raising are the
> ones that were raised to me when I started talking about the idea...
> A major design goal of memcache is to have all operations be roughly
> order 1. A notification system would be order n with the number of
> listeners on that key. Also, where would the memory for keeping
> track of
> listeners go?
I wasn't thinking about doing per-key notifications. I just want a
stream of invalidations.
The memory overhead would be roughly the same as any other
connection, although you'd want some simple structure you could use
to know what subscribers existed without having to look through *all*
I imagine the process would be triggered off of anything that would
reclaim space for a given key and basically queue an event for all
listeners to write out the key that got invalidated. It should be
possible for them all to share the same instance of the structure to
send and just decrement a reference count such that the last one
releases the structure.
So yeah, you'd be O(listeners), but the cost should be really low
there. Mostly just ensuring they're in a write state and have
something to write.
> I had originally thought that this would make the most sense with
> per-key notifications. Maybe it would be better to do this as a global
> notification system? That might entail adding one new keyword to the
> protocol which puts a TCP session into notification mode until the end
> of the session.
Right, this is what I was imagining.
More information about the memcached