Closed GoogleCodeExporter closed 9 years ago
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
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
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
looking into this
Original comment by CaptTo...@gmail.com
on 22 Oct 2009 at 3:17
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
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
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
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
Original issue reported on code.google.com by
shalmaneser@gmail.com
on 24 Jan 2009 at 10:49