a- correct me if I'm wrong?
I think you're seeing this behavior because of the deadTimeout which limits how often servers that have been considered "dead" are checked for being available again. In previous versions of the client this was set to 10 minutes and was not configurable. In more recent code changes (but not in a release) this is configurable through standard configuration and is defaulted to 2 minutes instead. I'm pretty sure you'll only get an exception for every operation if your entire server pool is "dead". Under normal production circumstances you would never take down all your memcached instances at once? Cheers, Kieran From: Ciaran [mailto:[EMAIL PROTECTED] Sent: 11 January 2008 09:20 To: Kieran Benton Cc: [EMAIL PROTECTED]; [email protected] Subject: Re: Application (memcached client) can not continue to usethememcached instances after a memcached restart ...(theapplication itself is not restarted) On Jan 11, 2008 8:57 AM, Kieran Benton <[EMAIL PROTECTED]> wrote: This has niggled with me for a while as well :) maybe its best that if we just detect a "connection reset" socket error code we swallow the error with stack and just log a one line warning? Oddly the stack always appears to be consumed anyway, but I don't really know how looking at the code!. But in this particular case its perhaps more of a warn level or info level message rather than an error. (I guess this is something that could be argued one way or t'other!). But once a server's down *every* 'get' throws the object reference not found [it seems in my current test configuration of a single memcached server], given that throwing exceptions is *relatively* expensive especially on an operation that you could ideally have returning immediately it would be great to avoid even bothering to attempt in this case. Please bear in mind I'm new to a)memcached and b)Enyim.memcahed client, so I could just have set things up incorrectly :) - Ciaran
