For what it is worth, I'm hesitant to upgrade memcached to the latest
version as a step to try and solve this issue. It seems to me that since
our installs have been running without issue for quite some time (close to
a year), that there are other variables at play here. I just don't
I just had another failure. After pulling down my apache web servers, and
before restarting memcached I grabbed stats to see if they showed anything
of interest:
- All 3 servers were reporting for duty following a getServerStatus (PHP
client call)
- curr_connections were listed as 8 across
Hi Mike, this sounds to me more like a client/coding error rather than
memcached server. That's where I would focus first.
Boris
On Wed, Nov 19, 2014 at 11:41 AM, labnext...@gmail.com wrote:
I just had another failure. After pulling down my apache web servers, and
before restarting memcached
Thanks Boris,
I haven't really given that much thought. Out of curiosity, why do you
think the issue might be on the client end? I ask, cause I really don't
have a sense of what to look for on that end and wonder if you might have
some suggestions.
Best,
Mike
On Wednesday, November 19,
You're probably getting spaces or newlines into your keys, which can cause
the client protocol to desync with the server. Then you'll get all sorts
of junk into random keys (or random responses from keys which're fine).
Either filtering those or using the binary protocol should fix that for
you.
Is the key got the wrong value always? or just sometime it is wrong? If it
always got wrong value, the wrong value trend to be wrong when it is stored(or
be overwrote); If it is just randomly got the wrong value, it should be
corruption at get command.
For the first case, you can use
Status: New
Owner:
Labels: Type-Defect Priority-Medium
New issue 384 by kelvin0...@gmail.com: memcached refuse to recv data if the
client send too much data without recving
https://code.google.com/p/memcached/issues/detail?id=384
(I’m not sure whether it is a bug or a feature.)
###
