增量超时;重试后设置总是成功 [英] Increment times out; set always succeeds after retry
问题描述
我在memcached中遇到了奇怪的行为,特别是在一致性方面很奇怪的行为.这是我的测试:
I'm getting strange behavior in memcached, in particular, behavior that is strange in its consistency. Here is my test:
@Test
public void testMemc() {
logger.info("Setting head.");
memc.set(env.memcachedQueueKeys().head, 3600, 0);
logger.info("Set head; incrementing.");
memc.incr(env.memcachedQueueKeys().head, 1);
logger.info("Incremented.");
}
这是输出:
28 11:04:52.932 INFO;放下头.
28 11:04:52.932 INFO; Setting head.
2014-01-28 11:04:52.933警告net.spy.memcached.MemcachedConnection:无法重新分配到另一个节点,请重试q:unittest:scannedemails:w的主节点.
2014-01-28 11:04:52.933 WARN net.spy.memcached.MemcachedConnection: Could not redistribute to another node, retrying primary node for q:unittest:scannedemails:w.
28 11:04:52.933 INFO;机头;递增.
28 11:04:52.933 INFO; Set head; incrementing.
2014-01-28 11:04:52.935警告net.spy.memcached.MemcachedConnection:无法重新分发到另一个节点,重试q:unittest:scannedemails:w的主节点.
2014-01-28 11:04:52.935 WARN net.spy.memcached.MemcachedConnection: Could not redistribute to another node, retrying primary node for q:unittest:scannedemails:w.
失败:testMemc
net.spy.memcached.OperationTimeoutException:突变操作超时,无法修改计数器[q:unittest:scannedemails:w]
在net.spy.memcached.MemcachedClient.mutate(MemcachedClient.java:1484)
在net.spy.memcached.MemcachedClient.incr(MemcachedClient.java:1529)
在me.unroll.emailroller.ActOnScanResultsTest.testMemc(ActOnScanResultsTest.java:295)
FAILED: testMemc
net.spy.memcached.OperationTimeoutException: Mutate operation timed out,unable to modify counter [q:unittest:scannedemails:w]
at net.spy.memcached.MemcachedClient.mutate(MemcachedClient.java:1484)
at net.spy.memcached.MemcachedClient.incr(MemcachedClient.java:1529)
at me.unroll.emailroller.ActOnScanResultsTest.testMemc(ActOnScanResultsTest.java:295)
我对这种错误的大多数直觉在这里使我失望.以下都是奇怪的事情:
Most of my intuition for this kind of error fails me here. The following things are all strange:
- 为什么总是总是一次设置失败?
- 为什么它似乎在设定成功后就永远无法递增?
这是在高负载服务器上的(是的,在承重服务器上运行测试是有点错误的,但是如果它捕获到这样的问题,则至少有一些优势).是什么导致这种持续的故障?只有一个节点.
This is on a high-load server (yes, it's a little wrong to be running a test on a load-bearing server, but if it catches issues like this there's at least some advantage). What can cause this consistent failure? There is only one node.
推荐答案
问题是我根本无法连接 .这是spymemcached中的一个错误,因为set
操作没有抛出异常,即使它没有用于执行set
的内存缓存服务器.
Problem is I couldn't connect at all. This is a bug in spymemcached, since the set
operation did not throw an exception even though it had no memcached server to perform set
on.
这篇关于增量超时;重试后设置总是成功的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!