spymemcached的get和incr方法给出的结果完全不同 [英] spymemcached get and incr methods give wholly different results

查看:131
本文介绍了spymemcached的get和incr方法给出的结果完全不同的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我在Java项目中使用spymemcached 2.6rc1,我想将Long类用作可存储对象.不幸的是,当我存储新的Long(0)对象,get(...)和incr(...)给出完全不同的结果-get给出包含48个值的Long对象,而incr给出1. 请注意,48表示ASCII"0"符号.当我尝试直接从memcached获取同一个键的值时(例如通过使用telnet),我得到了正确的结果-0.奇怪的是,Long是很好的序列化类.因此,默认转码可能存在一些问题.有人可以澄清如何解决这种情况吗?

I use spymemcached 2.6rc1 in my Java project where I want to use the Long class as a storable object. Unfortunately, when I store e.g. new Long(0) object, the get(...) and incr(...) give the wholly different results - get gives Long object that contains 48 value and incr gives 1. Please note that 48 represents the ASCII "0" symbol. When I try to get the value for the same key directly from memcached (e.g. by using telnet) I get the correct result - 0. Strange, the Long is good serialized class. So, probably, there is some problem with default transcoding. Can somebody clarify how to resolve this situation?

推荐答案

前一段时间存在此问题(spymemcached错误41).以下是Spymemcached的创建者Dustin Sallings对这个问题的评价:

There was an issue filed for this a while back (spymemcached bug 41). Here's what Dustin Sallings, the creator of Spymemcached said about the issue:

您不能混合使用IntegerTranscoder和incr/decr. incr/decr要求数字为 编码为字符串,因为它们是与语言无关的服务器端操作.

You can't mix IntegerTranscoder and incr/decr. incr/decr require the numbers to be encoded as strings as they are language-agnostic server-side operations.

这是一个单元测试,可以演示您要执行的操作:

Here's a unit test that demonstrates what you're trying to do:

public void testIncrDecrBug41() throws Exception {
    final String key="incrdecrbug41";

    // set to zero
    client.set(key, 86400, "0");

    // retrieve it to see if it worked
    assertEquals("0", client.get(key));

    // increment it
    assertEquals(1, client.incr(key, 1));

    // fetch it again to see if it worked
    assertEquals("1", client.get(key));
}

请注意,获得49的原因是因为十进制49是字符串"1".

Note that the reason you get 49 is because decimal 49 is the string "1".

incr和decr由于服务器端而给人们带来很多混乱 语义.在较新版本的memcached中(例如,我尚未在 我的二进制分支),incr和decr将在非数字字符串值上失败.那是, 您的第一个incr会引发异常.

incr and decr cause a lot of confusion for people because of the server-side semantics. In newer version of memcached (e.g. changes I don't have applied yet in my binary branch), incr and decr will fail on non-numeric string values. That is, your first incr would throw an exception.

将来,请在Spymemcached项目网站上提交错误.可以在 http://code.google.com/p/spymemcached 中找到.这样我们就可以更快地修复它们.

In the future please file bugs at the Spymemcached project website. It can be found at http://code.google.com/p/spymemcached. That way we can fix them sooner.

这篇关于spymemcached的get和incr方法给出的结果完全不同的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆