unexpected incr

[GoogleCodeExporter]

i'm using spymemcached2.2; windowsxp via memcached.exe.

it seems that the way spymemcached stores ints, and the way that the
memcached server interprets ints is different.

    int  o= (Integer)c.get("iz");// 0
    long v= c.incr("iz", 1);     // 1
    int  n= (Integer)c.get("iz");// 49

the server's incr turns the number 0 into a string '0001', but doesn't
alter the stored value's flags.  when spymemcached reads the value it still
sees it marked as int, but interprets the ascii value of "1" as the value
integer value 49.

the following example using strings shows how the server stores and
manipulates ints:

    c.set( "iz", 0, "0" );
    String o= (String)c.get("iz"); // "0"
    long   v= c.incr("iz", 1);     // 1
    String n= (String)c.get("iz"); // "1"

it might be worth having a way to adjust the transcoder behavior to choose
between a "server compatibility" mode and the current "optimized storage" mode.

Original issue reported on code.google.com by shalmaneser@gmail.com on 24 Jan 2009 at 10:49

[GoogleCodeExporter]

missed a line, sorry; the first example should have read:

    c.set( "iz", 0, 0 );
    int  o= (Integer)c.get("iz");// 0
    long v= c.incr("iz", 1);     // 1
    int  n= (Integer)c.get("iz");// 49

Original comment by shalmaneser@gmail.com on 24 Jan 2009 at 10:51

[GoogleCodeExporter]

Isn't this the same as Issue-41?
http://code.google.com/p/spymemcached/issues/detail?id=41

Original comment by kevinoliver on 22 May 2009 at 9:33

[GoogleCodeExporter]

It is.  I think the question is whether something smarter can be done about 
adjusting
flags or something.

Original comment by dsalli...@gmail.com on 22 May 2009 at 10:30

[GoogleCodeExporter]

looking into this

Original comment by CaptTo...@gmail.com on 22 Oct 2009 at 3:17

• Changed state: Accepted

[GoogleCodeExporter]

Verified. This is interesting- the output of the server:

<30 new auto-negotiating client connection
30: Client using the ascii protocol
<30 set iz 512 0 0
>30 STORED
<30 get iz
>30 sending key iz
>30 END
<30 incr iz 1
>30 1
<30 get iz
>30 sending key iz
>30 END
<30 connection closed.

zero seems to be the special case here. If I start out from 1:

memc.set( "iz", 0, 1 );

The subsequent incr fails, since 1 is being stored as a string value, hence 
cannot be
incremented:

patg@ishvara:~/code-dev/java$ java IncDecIssue 
2009-10-22 11:31:10.009 INFO net.spy.memcached.MemcachedConnection:  Added {QA
sa=/192.168.1.106:11211, #Rops=0, #Wops=0, #iq=0, topRop=null, topWop=null,
toWrite=0, interested=0} to connect queue
2009-10-22 11:31:10.013 INFO net.spy.memcached.MemcachedConnection:  Connection 
state
changed for sun.nio.ch.SelectionKeyImpl@1050e1f
2009-10-22 11:31:10.037 ERROR 
net.spy.memcached.protocol.ascii.MutatorOperationImpl:
 Error:  CLIENT_ERROR cannot increment or decrement non-numeric value
2009-10-22 11:31:10.038 INFO net.spy.memcached.MemcachedConnection:  
Reconnecting due
to exception on {QA sa=/192.168.1.106:11211, #Rops=1, #Wops=0, #iq=0,
topRop=net.spy.memcached.protocol.ascii.MutatorOperationImpl@bb6ab6, 
topWop=null,
toWrite=0, interested=1}
OperationException: CLIENT: CLIENT_ERROR cannot increment or decrement 
non-numeric value
    at net.spy.memcached.protocol.BaseOperationImpl.handleError(BaseOperationImpl.java:125)
    at net.spy.memcached.protocol.ascii.OperationImpl.readFromBuffer(OperationImpl.java:130)
    at net.spy.memcached.MemcachedConnection.handleReads(MemcachedConnection.java:361)
    at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:305)
    at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:192)
    at net.spy.memcached.MemcachedClient.run(MemcachedClient.java:1444)
2009-10-22 11:31:10.039 WARN net.spy.memcached.MemcachedConnection:  Closing, 
and
reopening {QA sa=/192.168.1.106:11211, #Rops=1, #Wops=0, #iq=1,
topRop=net.spy.memcached.protocol.ascii.MutatorOperationImpl@bb6ab6, 
topWop=null,
toWrite=0, interested=1}, attempt 0.
2009-10-22 11:31:10.041 WARN 
net.spy.memcached.protocol.ascii.AsciiMemcachedNodeImpl:
 Discarding partially completed op:
net.spy.memcached.protocol.ascii.MutatorOperationImpl@bb6ab6
2009-10-22 11:31:10.147 INFO net.spy.memcached.MemcachedConnection:  
Reconnecting {QA
sa=/192.168.1.106:11211, #Rops=0, #Wops=1, #iq=0, topRop=null,
topWop=net.spy.memcached.protocol.ascii.GetOperationImpl@1f630dc, toWrite=0,
interested=0}
2009-10-22 11:31:10.151 INFO net.spy.memcached.MemcachedConnection:  Connection 
state
changed for sun.nio.ch.SelectionKeyImpl@1c5c1
get o: 1
incr return : 0
get return : 1
2009-10-22 11:31:10.157 INFO net.spy.memcached.MemcachedClient:  Shut down 
memcached
client

So, zero must be different in that it is either stored as a null, zero, or 
string
zero and yet can be incremented.

Original comment by CaptTo...@gmail.com on 22 Oct 2009 at 3:44

[GoogleCodeExporter]

I believe the issue is that you can't use get() to fetch a value that's subject 
for
incr/decr.

I think the right thing is to just close this as a wontfix and tell people not 
to do it.

This was something I had attempted to fix in the server when doing incr/decr 
support
in the binary protocol, but the behavior that leads to this situation was 
insisted
upon for backwards compatibility.

While it may be possible to do something in the server, by far, the easiest 
thing is
to update the documentation to indicate that incr/decr and set/get don't mix in 
any
meaningful way.

Original comment by dsalli...@gmail.com on 22 Oct 2009 at 4:15

• Added labels: Component-Docs

[GoogleCodeExporter]

plan to document this for 2.5 release, per Dustin's recommendation.

Original comment by ingen...@gmail.com on 10 Mar 2010 at 4:32

[GoogleCodeExporter]

Documented the expected behavior based on the memcached server behavior per the
discussion above.

Original comment by ingen...@gmail.com on 12 Mar 2010 at 11:04

• Changed state: Fixed