Thanks for your response. On Nov 3, 6:09 pm, Dustin <[EMAIL PROTECTED]> wrote: > On Nov 3, 5:02 pm, sdeo <[EMAIL PROTECTED]> wrote: > > > We are very excited to use a production cluster to host our > > memcached servers for a web service. However I am a little bit unclear > > as to the behavior in a real-life prod. environment where servers are > > frequently being rebooted or swapped out and replaced (or new ones > > added). > > Such instability won't make for a very good environment of any kind. > > > 1) what happens when a server to which a particular key hashes is > > brought down, and restarted. Would the client (I am using the Java > > client btw) be able to figure out that a particular server is back up > > again transparently ? > > Which java client? Mine can, but it may very well be undesirable to > do that in your environment as it can introduce stale data.
We use "memcached-1.4.jar" from (http://bleu.west.spy.net/~dustin/ projects/memcached/downloads.html) which one do you use ?. We can handle stale data, what is important to us is handling server restarts. > > > 2) In case one of the servers is brought down for a extended period, > > would the keys that would have normally hashed continue to incur a DB > > hit since the hashing function would always map to that machine for a > > particular key or is there a way to have them start mapping to one of > > the remaining server instances ? > > No, they should map around the down servers quickly. How so ? So you mean if key "foo" was mapping to memcached "server A", and it goes down. The next time a client asks for "foo", it would hash first to "server A" which fails, so would the client then automatically remap to "Server B" ? It would be really helpful if you can please explain it a bit more. > > 3) Is there a way to make a live update to the list of servers that a > > client can use without restarting the client ? > > Not in my client. It'd be *possible*, but it's in no way > desirable. You're better off using guice to inject a client when you > need it and have it get the client from an AtomicReference that can be > swapped out with a complete client when stuff changes.
