Return-Path: Received: from vid.zoo.gr ([206.188.4.140] verified) by mx.softsearch.ru (CommuniGate Pro SMTP 5.1.14) with ESMTP id 63994709 for talk@openhack.ru; Fri, 22 Feb 2008 00:15:07 +0300 Received: from [192.168.1.100] (ip82-139-112-245.lijbrandt.net [82.139.112.245]) (Authenticated sender: kostas) by vid.zoo.gr (Postfix) with ESMTP id 28B511528043 for ; Thu, 21 Feb 2008 23:15:08 +0200 (EET) Message-ID: <47BDE9DD.1030106@chatzi.org> Date: Thu, 21 Feb 2008 22:15:09 +0100 From: Kostas Chatzikokolakis User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: talk@openhack.ru Subject: Re: Reconnections and mod_perl References: In-Reply-To: X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Thanks for the fast and very helpful answer. C::M::F works exactly as I was hoping :D So, based on this, if I use cache from many different parts of my application, instead of creating many C::M::F objects with different namespaces, it's better to use just one and add the needed prefixes myself, to reuse the same connections and avoid opening too many. Isn't it? Kostas Tomash Brechko wrote: > On Thu, Feb 21, 2008 at 20:31:52 +0100, Kostas Chatzikokolakis wrote: >> I'd like to ask wether Cache::Memcached::Fast keeps connections to >> memcached servers open, and if so, does it reconnect in case a >> connection drops? > > Yes for both questions. Upon the request to a particular server > (which servers will be used depends by requested keys), if there's no > connection to the server yet, C::M::F connects to it (or gives up > after connect_timeout seconds). The module doesn't close the > connection until either: > > - C::M::F is destroyed. > > - server sends error CLIENT_ERROR, SERVER_ERROR, ERROR, and > close_on_error is set (default). These errors are very unlikely > to happen, but when they do, it's better to close the connection > to avoid out-of-sync protocol state. > > - connection drops. > > Connection drop is detected during request processing. In this case > C::M::F closes it's local endpoint, and request processing is > continued unless all requested servers are dead. Then everything > starts from the beginning: when the new request comes C::M::F again > sees that there's no connection to the server, and tries to reconnect. > You will likely want to set > > max_failures => 1, > failure_timeout => 5, > > where 5 is number of seconds after failure during which no reconnect > attempt will be maid in order to not waste all the time trying to > reconnect to dead memcached over and over again. > > As said above, failure of one server does not affect the requests to > other servers. In particular multi-key request will succeed for all > keys but those dispatched to the failed server. > > >> I want to use the module under mod_perl, and the natural thing to do is >> to keep a pool of C::M::F objects in a global hash, to avoid creating a >> new object in each request (similarly to what Apache::DBI does for DBI). > > AFAIK some people use it exactly this way. > >