<<Is it possible that some requests to memcached remain in a blocking <<state since there is no timeout specified?
As fare as I know, the only blocking that may occur is that you fill up operation queues, and offer() calls will start blocking and timing out after 10 seconds (default value). But it won't be because there is no timeout specified, but because of some bug in your app which allows to uncontrollably fire large number of async requests. That timeout only matters if you call methods synchronously. One thing that might happen if you don't explicitly control returned Future object, is depending on what you set FailureMode to be, the failed operations may get re-queued/reprocessed infinitely. <<I see in the API a reference to global operation timeout. I wonder <<what that is. global operation timeout is what you set on DefaultOperationfactory (and it defaults to 1 sec). It only matters if you use synchronous methods. E.g. get() vs asyncGet(). Essentially you can use majority of methods in spy API in 3 different ways: 1. async "fire and forget". You call methods like set(), asyncGet() and ignore returned Future object. In this case none of the timeouts available on operation factory matter. 2. async and take control of returned Future object. You call methods like set(), asyncGet() and then call get(timeout) on the future object. In this case you control how long to wait for return with passed in timeout (or default timeout is used if you call get()). You can catch Timeout exception and call future.cancel() if you don't want the operation to stay in the queue. 3. Some (but not all) methods are available in synchronous flavor (get(), getBulk()). In this case you don't have to manage Future objects, they will block internally for the duration of global timeout value. Boris On Wed, May 19, 2010 at 5:38 PM, Harry Duin <harry.d...@gmail.com> wrote: > Is it possible that some requests to memcached remain in a blocking > state since there is no timeout specified? > > I see in the API a reference to global operation timeout. I wonder > what that is. > > -hd > > On May 19, 2:56 pm, Boris Partensky <boris.parten...@gmail.com> wrote: > > Sorry, just re-read the question. You are just doing an async set here, > so > > no timeout is relevant. > > The operation will be queued up and processed. I suppose if you fire tons > of > > those, then it's possible to fill up the queues, > > so the future requests will start blocking waiting for the queue to > drain. > > > > On Wed, May 19, 2010 at 3:42 PM, Boris Partensky > > <boris.parten...@gmail.com>wrote: > > > > > > > > > <<Can anyone tell me if the set operation has a timeout even if I don't > > > <<specify one? > > > > > I think it defaults to 1 sec (defined in DefaultConnectionFactory > class) > > > > > On Wed, May 19, 2010 at 3:11 PM, Harry Duin <harry.d...@gmail.com> > wrote: > > > > >> I am using the package net.spy.memcached and noticed that the set > > >> method uses a Future<Boolean> but my code is not using that return > > >> value, i.e. I am not invoking a get on the Future to see the result of > > >> the set. > > > > >> Can anyone tell me if the set operation has a timeout even if I don't > > >> specify one? I am a bit concerned that there is no timeout and I can > > >> take up system resources. Just today I got over 3k timeouts on the get > > >> call, who is using the Future to verify the result. > > > > >> I am using the timeout feature of Future on the get methods I have. Is > > >> it recommended that I use that for the set/add/delete methods as well? > > > > >> Harry- Hide quoted text - > > > > - Show quoted text - >
