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? > > This is exactly the scenario I have at the minute, as on development machines there's only one memcached instance, if that dies or is un-available for some reason effectively the 'whole pool' is dead. I totally understand this is unlikely, I'm just wondering if it could be handled in a neater way ? (it may not be possible or sensible to do this, as you say this is an 'error' state :) ) - ciaran
> > > 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 > > > -- - Ciaran
