CheckedOperationTimeoutException after brief network down

[GoogleCodeExporter]

What version of the product are you using? On what operating system?

Client: 2.8.1
Server (Centos5): memcached.x86_64 1.4.7-1.el5.rfx 

Setup

---

Development tomcat on local dev machine on wifi
Remote memcached server

Steps to reproduce
-----

1. Start tomcat which inits client pool
2. Run as normal, getting and setting data to server
3. Switch wifi network (after freeze)
4. Get requests to server produce:

net.spy.memcached.internal.CheckedOperationTimeoutException: Timed out waiting 
for operation - failing node: blah.transmachina.net/1.2.3.4:11211
    at net.spy.memcached.internal.OperationFuture.get(OperationFuture.java:93)
    at net.spy.memcached.internal.GetFuture.get(GetFuture.java:62)
    at transmachina.perf.Memcached.getAsync(Memcached.java:331)

Debug log later shows:

2012-08-11 16:28:02.592 WARN 
net.spy.memcached.protocol.ascii.AsciiMemcachedNodeImpl:  Discarding partially 
completed op: Cmd: get Keys: sJ:wbr:120:33177300000n'en Exp: 0
2012-08-11 16:28:02.593 INFO net.spy.memcached.MemcachedConnection:  
Reconnecting due to exception on {QA sa=blah.transmachina.net/1.2.3.4:11211, 
#Rops=1, #Wops=0, #iq=0, topRop=Cmd: get Keys: sJ:wbr:120:1023400000gif Exp: 0, 
topWop=null, toWrite=0, interested=1}
java.io.IOException: Operation timed out
    at sun.nio.ch.FileDispatcher.read0(Native Method)
    at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:21)
    at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:198)
    at sun.nio.ch.IOUtil.read(IOUtil.java:166)
    at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:245)
    at net.spy.memcached.MemcachedConnection.handleReads(MemcachedConnection.java:438)
    at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:380)

We've seen similar errors in the test server logs. Is it possible that it's a 
network hiccup causing those too? Shouldn't it automatically reconnect when 
each client in the pool is queried? Or do I need to catch this and 
re-initialise the memcache client myself?

Original issue reported on code.google.com by nic%tran...@gtempaccount.com on 11 Aug 2012 at 4:31

[GoogleCodeExporter]

Also, if your memcached process die the same error happens. What is curious 
about it is that it only happens the first time you call MemcachedClient.get, 
all subsequent calls ignores the fact that the server is offline and returns 
null.

Original comment by Jayrmo...@gmail.com on 11 Sep 2012 at 6:47

[GoogleCodeExporter]

I'm facing facing similar issues with spymemcached v2.7 on windows 7. If the 
spymemcached server goes down during normal operation, the client keeps 
attempting to reconnect to the spymemcached server. Is there a particular 
setting that delays the attempt to reconnect to the server (the reconnection 
attempts are causing delay)? I've found the 'maxReconnectDelay' property of the 
MemcachedClientFactoryBean, but don't understand its effects. Also I set 
'opTimeout' to a low value (1 millisec), but I would rather that no 
reconnection attempts were made at all in the specified time period. Any ideas?

Original comment by arindam....@gmail.com on 16 Oct 2013 at 1:18

[GoogleCodeExporter]

@nic: those log messages are likely related to changing networks, yes.  You 
shouldn't need to manage the reconnection.  As long as the host is reachable, 
the client will automatically reconnect.  It'll keep trying to do so forever.

@arindam.rc.08: you shouldn't need to do anything special.  the behavior of the 
client if a connection is lost is that it will try to reconnect in background.  
It will do so with an exponential backoff until it successfully reconnects.  
Any operations you try while it's not connected will immediately fail.

All of those reconnects will generate log messages, but they shouldn't cause a 
problem.

Original comment by ingen...@gmail.com on 31 Oct 2013 at 6:57

[GoogleCodeExporter]

I don't think there's anything that needs to be done here, so I'm closing it 
for now, but let me know if it should be reopened.

Original comment by ingen...@gmail.com on 31 Oct 2013 at 6:58

• Changed state: Invalid