I don't actually know how yahoo's imeplentation works, but before anyone
goes off the deep end:
- dumping in protocol format is a good idea.
- because you don't have to write code to reload that data.
- and you can edit it.
- but you might have to translate the expires times into explicit dates.
PlumbersStock.com ... if that is your real name, can you please be a
little more polite with the list?
Memcached has a long history (notable excerpts of which have been pasted
for your reading pleasure) of hashing out this feature. While we've agreed
that one adhering to the constraints listed above (ie; no explicit funky
dump/reload format) might be accepted, I would hope you don't view us (and
hope others don't get the impression of us as) a bunch of idiots who don't
understand your problems.
This approach simply doesn't work for most of us. I've already seen some
good suggestions of alternatives you could implement with technology that
exists today, without paying a bounty, and would work just fine. No need
to complain.
One idea would be to actually use an existing fork, like memcachedb. Sure,
our ultimate goal is to fold that feature back in, but hey it exists now
and someone spent some effort into making that fork.
Another method would be to just cache into MySQL and use the
libmemcached-based MySQL UDF's to update memcached. I suspect you've only
got the one box? Maybe two?
If not, it's not terribly hard to switch to a libmemcached based client.
If it is hard you can still do this without the UDF's... They just need to
be consistent on both ends so the key hashing lines up. Which doesn't
matter if you only have the one box.
Anyway, nothing fancy. Just create tables with the key, flags, expiredate,
value. INSERT into MySQL and SET into memcached at the same time. Then
read off of memcached. Then you just need a simple wrapper that SELECT *
FROM table WHERE expiredate > NOW(); and reload your data. From the
description of your awful horrible terrible backend system, it sounds like
it'd benefit you more from being able to fall back to MySQL on a memcached
cache miss anyway.
Most of us view these various scalability tools more like UNIX programs
than a batshit huge enterprise system. The idea is to take simple concepts
and plug them together on until they work.
-Dormando
On Wed, 10 Sep 2008, PlumbersStock.com wrote:
In that case.. Would anyone be interested in collecting a bounty on
getting a save/restore feature created that would be accepted into the
main branch? What would be a fair bounty for something like this?
Option to save all items in memory to hdd on shutdown of memcached.
Option to load saved items from hdd to memory on start of memcached.
Option to load, in addition to memory dump, a changes list from a text
file (some simple to produce format - up to you) on start of
memcached. Changes would include anything memcached can be asked to
do.
On Sep 10, 9:02 pm, "Clint Webb" <[EMAIL PROTECTED]> wrote:
I've not seen any patches submitted that do this. The other things that do
this are either different products, supplemental products, or forks that
attempt entirely different things (but happen to do what you are after).
I expect a well implemented patch that does this would be accepted into the
main branch.
On Thu, Sep 11, 2008 at 10:32 AM, PlumbersStock.com <
[EMAIL PROTECTED]> wrote:
It sounds as if this feature has been added by others already and
hasn't found it's way into the main tree. Maybe it just wasn't coded
well enough to make it in. It seems it should be a really simple
feature to add, that shouldn't interfere with the running cache in any
way, and those whose use of the cache would make using save/restore a
bad thing could just choose not to use it. I can understand not adding
features that would have a negative impact on the project but stuff
that is essentially painless I can't understand leaving out. Project
management is never fun. At least with open source projects if I have
to have the feature I don't have to pay $300+ an hour and wait months
to get it done.
On Sep 10, 8:23 pm, "Stephen Johnston"
<[EMAIL PROTECTED]> wrote:
One would hope that any important contribution, written by a competent
developer, would find it's way into the main trunk of code instead of
forking. This is the catch-22 of open source. It really becomes a project
managment excercise.
On Wed, Sep 10, 2008 at 10:10 PM, PlumbersStock.com <
[EMAIL PROTECTED]> wrote:
The problem with any software though is that if you can't convince the
owner of the software to add your feature into the main tree then
you're forever playing catchup.
--
"Be excellent to each other"
