roc230 / spymemcached

Automatically exported from code.google.com/p/spymemcached
0 stars 0 forks source link

reconnects and cas #76

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
I'm using memcached-2.3.1.jar on OSX 10.5.7.

I've been testing reconnects/retries by starting a memcached server, starting a 
MemcachedClient, killing the memcached server, and 
then attempting an operation via the client.  The scenario I actually want to 
support is a server becoming temporarily unreachable (not 
going down).

Automatic retries seem to work well for gets, add, and delete operations, but 
cas operations always get canceled immediately.  Is this a 
bug, or is there a reason it's difficult to re-queue a cas operation?

2009-06-22 10:44:19,001 [Memcached IO over {MemcachedConnection to 
localhost/127.0.0.1:11312}] WARN  
net.spy.memcached.MemcachedConnection - Closing, and reopening {QA 
sa=localhost/127.0.0.1:11312, #Rops=1, #Wops=0, #iq=0, 
topRop=net.spy.memcached.protocol.ascii.CASOperationImpl@691872a8, topWop=null, 
toWrite=0, interested=1}, attempt 0.

2009-06-22 10:44:19,003 [Memcached IO over {MemcachedConnection to 
localhost/127.0.0.1:11312}] WARN  
net.spy.memcached.protocol.ascii.AsciiMemcachedNodeImpl - Discarding partially 
completed op: 
net.spy.memcached.protocol.ascii.CASOperationImpl@691872a8

Thanks!

Original issue reported on code.google.com by x%xtophe...@gtempaccount.com on 22 Jun 2009 at 2:59

GoogleCodeExporter commented 9 years ago
Actually, my test was broken.  E.g. I was testing add retries on a client which 
had never been successfully 
connected.  Add operations also get discarded if the client lost a connection 
(vs. trying to connect for the first 
time).  

Would it be safe for the client to re-queue in cases like this, or is it 
possible that the operation got through?

Original comment by x%xtophe...@gtempaccount.com on 22 Jun 2009 at 3:25

GoogleCodeExporter commented 9 years ago

Original comment by mikewie...@gmail.com on 12 Sep 2011 at 7:31