spymemcached get and incr methods give wholly different results

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 situati开发者_如何学编程on?

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:

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));
}

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

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.

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.