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 <[email protected]> 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 > <[email protected]>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 <[email protected]> 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 -
