Suggestion for OperationTimeoutExceptions about spymemcached

[GoogleCodeExporter]

What are you wanting to know, exactly?  Can you give me examples of how you 
might
imagine this working?

Original comment by [email protected] on 27 Jun 2008 at 5:59

[GoogleCodeExporter]

I would find it very useful to see the address of the memcached node that 
caused the
timeout.

e.g. 
try
{
  client.get(key);
}
catch (OperationTimeoutException e)
{
   // getNodeInfo() could be the SocketAddress to identify the node
   log.error("Node that caused timeout: " + e.getNodeInfo());
   // or maybe just add the node address to meesage?
   log.error("Node that caused timeout: " + e.getMessage();
}

Does this make it clearer?

Original comment by [email protected] on 27 Jun 2008 at 11:08

[GoogleCodeExporter]

+1 For this - the IP address of the node that the timeout occurred on would be 
super
useful for debugging network-related issues in setups with hundreds of memcache 
machines.

Original comment by massdosage on 30 Jun 2008 at 11:02

[GoogleCodeExporter]

Currently we see this in our logs (using 2.1):

[2008-11-02 13:56:41] ERROR 
net.spy.memcached.OperationTimeoutException: Mutate operation timed out, unable 
to
modify counter [da5a963177c779f86fec2618036175f3]
        at net.spy.memcached.MemcachedClient.mutate(MemcachedClient.java:1050)
        at net.spy.memcached.MemcachedClient.mutateWithDefault(MemcachedClient.java:1089)
        at net.spy.memcached.MemcachedClient.incr(MemcachedClient.java:1126)
        at
fm.last.memcached.spy.MemCachedClientAdaptor.incr(MemCachedClientAdaptor.java:18
6)

We have roughly 100 memcache nodes. From this stack trace it is impossible to 
tell
which of the nodes is causing the problem. It would be great if the exception 
message
said something along the lines of:

Mutate operation timed out on 111.222.333.444

That would help in cases where there is an issue with just one of the nodes as 
only 
its IP address would show up in the logs. If lots of IP's showed up then it 
would
point in the direction of a more general failure. Either way, having that 
additional
information there would help debugging the cause of timeouts.

Original comment by massdosage on 20 Nov 2008 at 5:53

[GoogleCodeExporter]

It's a bit more complicated than this, but you can get the actual node that 
should've
been handling the operation from the root cause exception of the
OperationTimeoutException (as attached to the operation itself).

A stack trace print will show the information as well.

It's not guaranteed to report an actual problem with the node, but it should 
satisfy
this request.

Original comment by [email protected] on 18 Sep 2009 at 6:47

• Changed state: Fixed