memcached
simonsww / memcached Goto Github PK
View Code? Open in Web Editor NEWAutomatically exported from code.google.com/p/memcached
Automatically exported from code.google.com/p/memcached
memcached
http://code.google.com/p/memcached/wiki/MemcacheBinaryProtocol
getk/getkq response example:
Total body (8-11) : 0x00000009
Total body len should be 14 bytes, not 9 bytes
Original issue reported on code.google.com by [email protected]
on 4 Dec 2008 at 12:15
__What steps will reproduce the problem?__
1. Start memcached with a big memory limit (e.g. -m 1024)
2. Populate this memcached instance with a rate of 1 MB per second, where
each item has a validity timeout of 16 seconds. Use random strings or
numbers as keys.
__What is the expected output?__
It is expected that the memory allocated by memcached is about 16 MB (+some
overhead), because after filling memcached with 16MB worth of data, the
items start to become invalid, thus, the rate of items becoming invalid is
the same as the rate of new items. Thus, the amount of memory needed
remains rougly 16MB.
__What do you see instead?__
The memory allocated by memcached increases, until reaching a limit at
around 1024MB. Thus, memcached consumes much more memory than needed.
Memcached should be conservative with memory, and free old (invalid) items
first before requesting new memory from the operating system.
__What version of the product are you using? On what operating system?__
memcached 1.2.2 on Linux 2.6.18-6-amd64
__Please provide any additional information below.__
Original issue reported on code.google.com by [email protected]
on 6 Feb 2009 at 10:48
To reproduce, start a telnet to memcached...
> set a 0 0 1
> 1
STORED
> incr a 10000
10001
> get a
VALUE a 0 5
10001
END
> decr a 10000
1
> get a
VALUE a 0 5
1
END
The number of bytes after the big decr is 5, and perhaps it should be 1.
For example...
> get a
VALUE a 0 1
1
END
Original issue reported on code.google.com by [email protected]
on 1 Apr 2009 at 2:37
Should we add a command line option to disable the flush command?
Original issue reported on code.google.com by [email protected]
on 20 Apr 2009 at 6:14
What steps will reproduce the problem?
1. Everytime the cache does not contain the expected data length
What is the expected output? What do you see instead?
the python module should send an _Error exception:
Read %d bytes, expecting %d, read returned 0 length bytes
but instead, we have this one:
python_memcached-1.43-py2.6.egg/memcache.py", line 913, in recv
TypeError: %d format: a number is required, not str
What version of the product are you using? On what operating system?
not related to memcached himself. The issue comes from python-memcache-1.43
Please provide any additional information below.
to fix, I guess you should replace in line 913:
'read returned 0 length bytes' % ( len(buf), foo ))
by
'read returned 0 length bytes' % ( len(buf), rlen ))
Original issue reported on code.google.com by [email protected]
on 10 Mar 2009 at 3:48
We need a description for:
-C - Disable use of cas
-R - Number of requests processed per event
Original issue reported on code.google.com by [email protected]
on 16 Mar 2009 at 12:37
Patch from Domas:
if (daemonize) {
signal(SIGHUP,SIG_IGN);
}
Original issue reported on code.google.com by [email protected]
on 11 Apr 2009 at 10:49
I have an easy fix, but I need to write a test for it.
Original issue reported on code.google.com by [email protected]
on 13 May 2009 at 4:54
Some (old?) versions of the "tr" command don't interpret '\t' as "tab"
-rather it is read as the letters "\" and "t".
I've found that using the tab key, not the "tab" character "\t" always
seems to work.
Under the "memcached_dtrace.h" target in Makefile I substituted tr '\t' ' '
with tr ' ' ' '. where I used the tab key between the first two '
charachters. It would be nice if someone could shed light on why "\t"
wouldn't always work.
memcached_dtrace.h: memcached_dtrace.d
${DTRACE} -h -s memcached_dtrace.d
sed -e 's,void \*,const void \*,g' memcached_dtrace.h | \
sed -e 's,char \*,const char \*,g' | tr '\t' ' ' > mmc_dtrace.tmp
mv mmc_dtrace.tmp memcached_dtrace.h
changed to
memcached_dtrace.h: memcached_dtrace.d
${DTRACE} -h -s memcached_dtrace.d
sed -e 's,void \*,const void \*,g' memcached_dtrace.h | \
sed -e 's,char \*,const char \*,g' | tr ' ' ' ' > mmc_dtrace.tmp
mv mmc_dtrace.tmp memcached_dtrace.h
Original issue reported on code.google.com by [email protected]
on 23 Feb 2009 at 12:43
I'm using the standard Debian Lenny package for memcached version 1.2.2-1
1.) Client connects to memcached
2.) Client writes "set foo 0 10 3\r\nbar\r\n" to the output stream
3.) Client closes the output stream
4.) Client reads from the input stream
5.) Client closes connection
About 1 in 10 of these I don't get a response and the data isn't stored. I
think it's a race condition caused by memcached thinking that because I
closed the output stream that means I closed the socket?
You could say that I should just remove step 3 from my code but I'm
actually using a configuration option of a third party application (the
Exim mail server) so it's not my own code...
Original issue reported on code.google.com by [email protected]
on 13 May 2009 at 3:48
typedef protocol_binary_response_no_extras protocol_binary_response_nnoop;
should be :
typedef protocol_binary_response_no_extras protocol_binary_response_noop;
Original issue reported on code.google.com by [email protected]
on 4 Dec 2008 at 12:07
The binary protocol version has added test code coverage (gcov, tcov) to
the memcached-debug binary. When running "make test" the first test,
00-startup, will hang for approx. 30 secs. This only happens with gcov (not
tcov). The 00-startup test starts two memcached instances and when the test
is finished both instances will receive SIGINT at the same time. The gcov
processing taking place simultaneously in both memcached instances before
exit makes the processes hang. One possible fix is to send SIGINT to the
first memcached instance before starting up the next instance.
In 00-startup.t
add the line "kill 2, $server->{pid};" :
#!/usr/bin/perl
use strict;
use Test::More tests => 3;
use FindBin qw($Bin);
use lib "$Bin/lib";
use MemcachedTest;
my $server = new_memcached();
ok($server, "started the server");
kill 2, $server->{pid};
eval {
my $server = new_memcached("-l fooble");
};
ok($@, "Died with illegal -l args");
eval {
my $server = new_memcached("-l 127.0.0.1");
};
is($@,'', "-l 127.0.0.1 works");
Original issue reported on code.google.com by [email protected]
on 19 Feb 2009 at 12:52
1)
The textual delete command w/expire time in the binary protocol version:
It's now possible to add and replace an item inside the expiry time window
that was previously set when the item was deleted with an expiry time.
e.g. :
"delete foo 10\r\n" returns "DELETED\r\n"
"add foo 0 0 7\r\nfoo-add\r\n" returns "STORED\r\n" instead of "NOT_STORED\r\n"
"replace foo 0 0 11\r\nfoo-replace\r\n" returns "STORED\r\n" instead of
"NOT_STORED\r\n"
2)
The textual delete command with both expire time and noreply:
e.g.
"delete noreply:foo 10 noreply" returns "ERROR\r\n".
Two things are wrong: 1) There should be no reply. 2) Any reply should've
been either "DELETED\r\n" or "NOT_FOUND\r\n".
Original issue reported on code.google.com by [email protected]
on 27 Nov 2008 at 11:49
[deleted issue]
It should be possible to detect the number of bytes actually allocated in a
given slab class to make it easier to detect if one is using the wrong
growth factor.
Original issue reported on code.google.com by [email protected]
on 7 Apr 2009 at 10:55
There's a growing number of "extended" options that I think could be added.
Code's been written for this, so it just needs to go one way or the other.
The current work can be found here:
http://github.com/dustin/memcached/commits/oparam
Original issue reported on code.google.com by [email protected]
on 18 Mar 2009 at 8:37
Steps to reproduce:
weirdan@virtual-debian:/home/sam/trunk/test/unit$ echo $((2**63-1))
9223372036854775807
weirdan@virtual-debian:/home/sam/trunk/test/unit$ telnet localhost 11211
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
stats
STAT pid 590
STAT uptime 84394
STAT time 1235062054
STAT version 1.2.6
STAT pointer_size 32
STAT rusage_user 0.220013
STAT rusage_system 3.184199
STAT curr_items 683
STAT total_items 7293
STAT bytes 293187
STAT curr_connections 6
STAT total_connections 503
STAT connection_structures 16
STAT cmd_get 15597
STAT cmd_set 7291
STAT get_hits 8319
STAT get_misses 7278
STAT evictions 0
STAT bytes_read 7525934
STAT bytes_written 7270772
STAT limit_maxbytes 67108864
STAT threads 1
END
set aaa 0 0 19
9223372036854775807
STORED
get aaa
VALUE aaa 0 19
9223372036854775807
END
incr aaa 1
9223372036854775808
incr aaa 1
9223372036854775809
decr aaa 1
0
quit
Connection closed by foreign host.
weirdan@virtual-debian:/home/sam/trunk/test/unit$
Expected output:
decr should return 9223372036854775808
Memcache Version 1.2.6, running on debian linux 32bit, compiled with:
weirdan@virtual-debian:/home/sam/trunk/test/unit$ gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.3-3' --
with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-
languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-
system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-
threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --
program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-
objc-gc --enable-mpfr --enable-targets=all --enable-cld --with-tune=generic
--enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --
target=i486-linux-gnu
Thread model: posix
gcc version 4.3.3 (Debian 4.3.3-3)
The reason for this problem seems to be on this line:
http://consoleninja.net/gitweb/gitweb.cgi?
p=memcached.git;a=blob;f=memcached.c;h=3b7a187f726d4eb6ca5ae9684a3edaca984f
e58b;hb=HEAD#l1580
1580 if (delta >= value) value = 0;
where signed long long int delta is compared to unsigned long long value.
Original issue reported on code.google.com by weirdan
on 19 Feb 2009 at 4:56
What steps will reproduce the problem?
<?php
$memcache = new Memcached;
$memcache->addServer('127.0.0.1',11211);
$k = 'membugtest';
$memcache->delete($k);
$memcache->add($k,'string');
var_dump($memcache->get($k));
$memcache->delete($k,3600);
var_dump($memcache->get($k));
What is the expected output? What do you see instead?
First time the output is:
string(6) "string"
bool(false)
Next times:
bool(false)
bool(false)
Excepted output is the following at any time:
string(6) "string"
string(6) "string"
What version of the product are you using? On what operating system?
Memcached 1.2.6 under FreeBSD.
Original issue reported on code.google.com by [email protected]
on 25 Mar 2009 at 5:11
I tried to modify my log4j.xml to turn the logging for memcached off.
The only thing that seemed to turn it off was
<category name="STDERR"><priority value="OFF"/></category>
That shut off alot of things though.
Is there a way I can just shut the log messages off for the memcached?
Original issue reported on code.google.com by [email protected]
on 12 Feb 2009 at 2:17
Basically, it appears that the integrity of 'cas' is tainted. Both
the 'incr' and 'decr' operations do not update the cas ID of the key.
I realize that this is a fringe case, but I think for something like
'cas' to be effective and reliable, it needs to stay true to its
principal. I should be guaranteed that when the cas command accepts
my update, that I am replacing the value I think I am. See below for
an example of the current behavior:
set test 0 0 1
0
STORED
gets test
VALUE test 0 1 2 # CAS ID is 2
0
END
incr test 1
1
gets test
VALUE test 0 1 2 # CAS ID is still 2, despite the key's value
changing
1
END
cas test 0 0 1 2
9
STORED # This would've succeeded no matter when I got
that
cas ID. It's useless.
gets test
VALUE test 0 1 3
9
END
Original issue reported on code.google.com by [email protected]
on 12 Feb 2009 at 1:23
The binary protocol tries to cast the rcurr pointer to a structure and
dereference the structure. This does not work very well if rcurr points to
an unaligned address. This will only occur if you are pipelining multiple
commands so that read may return data for more than one memcached command.
Original issue reported on code.google.com by [email protected]
on 27 Nov 2008 at 8:22
Hi!
The reallocation size in grow_stats_buf() in memcached.c is incorrect, thus
causes a
segmentation fault when we encounter a large stats output (e.g. when the daemon
has over 40
slab classes).
We only reallocate the number of bytes that will accommodate the "needed" size
plus a little
more from doubling the nsize variable. The problem is that we realloc() based
on this size. What
we need to do is add the offset size to guarantee enough size:
realloc(c->stats.buffer, nsize + c->stats.offset);
Here's the patch on github:
http://github.com/tmaesaka/memcached/commit/404fd37417a6758d468d8c9f70e4c643c2b8
9
051
Cheers,
Toru
Original issue reported on code.google.com by tmaesaka
on 6 Apr 2009 at 6:05
file: memcached.c
function: static void process_bin_stat(conn *c)
defect code: } else if (strcmp(subcommand, "reset") == 0) {
correct code: } else if (strncmp(subcommand, "reset", 5) == 0) {
Original issue reported on code.google.com by [email protected]
on 26 Nov 2008 at 10:23
The current maximum key length limit (250 bytes) should be dropped
altogether, because it is artificial and arbitrary, and because it
complicates the usage of memcached unnecessarily.
As far as it concerns the code of memcached, the limit is purely artificial.
There may be reasons for having a small key length (speed; memory
consumption), but there may also be reasons for a large key length
(correctness (exact match vs. match of hash values); ease of use (no need
for workarounds around key lengths limits); ease of debugging (see keys in
cleartext, not as hashed text); less surprises when the limit is reached
only occasionally). Thus, memcached should not decide a priory on an
arbitrary limit.
Clients (and servers, too) are are allowed to warn about inefficiencies
pertaining to key length (e.g. if the key length exceed 250 bytes), but
they should continue to work if they can, and they can.
Thus, the limit should be dropped from the server as well as from the protocol.
Original issue reported on code.google.com by [email protected]
on 9 Jan 2009 at 5:29
memcached-tool does not display evicted items.
also it has a slightly odd display if the memcache is quite big (some GB)
and has long holding times.
this diff here helps in both cases.
Original issue reported on code.google.com by [email protected]
on 11 May 2009 at 10:53
The introduction of the -b parameter broke the -C parameter and didn't
properly handle the argument of -b
I've fixed this with a test atop the "stats settings" change and used that
feature to verify the effect, but it may need to be backported if the
community has issues with "stats settings".
Original issue reported on code.google.com by [email protected]
on 18 Mar 2009 at 7:16
hi, i want to know memcached installation steps for Drupal.
if you have any suitable link, or some thing please provide me,
memcache server is running, but it's not working for drupal. "What is this
PECL".
Kamlesh Patidar
Original issue reported on code.google.com by [email protected]
on 23 Oct 2008 at 7:52
function: process_bin_stat :
.
.
} else if (strncmp(subcommand, "detail", 6) == 0) {
.
.
.
if (strncmp(subcmd_pos, " dump", 5) == 0) {
.
.
.
bufpos = buf;
nbytes = append_bin_stats(bufpos, "detailed",
strlen("detailed"), dump_buf, len, (void *)c);
bufpos += nbytes;
nbytes += append_bin_stats(bufpos, NULL, 0, NULL, 0, (void *)c);
The last append_bin_stats command writes past the end of "buf" and causes
memcached to crash or hang sometimes. Just removing this command is the
solution?
Original issue reported on code.google.com by [email protected]
on 12 Feb 2009 at 7:01
What steps will reproduce the problem?
1. apply the attached patch (udp.t.diff) to t/udp.t
2. run the udp test (prove ./t/udp.t)
What is the expected output? What do you see instead?
-Expected: All tests should pass
-Actual: the set test fails and hangs
What version of the product are you using? On what operating system?
-1.3.2. running on Mac OS X (10.5.6)
Please provide any additional information below.
-The problem appears to be due to the fact that the complete_nread() function
does not handle
the udp protocol (c->protocol == ascii_udp_protocol). Already have a patch,
will submit it to
the mailing list.
-FWIW, glancing at the code suggest that there is no support for any UDP
operations using
binary protocol. Will create a test and file a bug as appropriate.
Original issue reported on code.google.com by [email protected]
on 20 Mar 2009 at 10:58
Attachments:
binary protocol version:
get command increments refcount but doesn't decrement after command is
finished. The item cannot be evicted after this.
Works if adding a few lines to reset_cmd_handler function but not sure if
this is 100% fixing refcount problem in binary protocol version
static void reset_cmd_handler(conn *c) {
if (c->item != NULL) {
item_remove(c->item);
c->item = 0;
}
Original issue reported on code.google.com by [email protected]
on 12 Feb 2009 at 12:14
Details of the -D parameter is not included in the usage() output.
Original issue reported on code.google.com by [email protected]
on 18 Mar 2009 at 12:32
They are currently installed if you run make install
Original issue reported on code.google.com by [email protected]
on 23 Mar 2009 at 6:57
What steps will reproduce the problem?
1. run: memcached -d -c 64 -vv -s mem.socket
2.
3.
What is the expected output? What do you see instead?
I expect the daemon to run as normal.
I see a bind(): Permission Denied error. Could this be caused by the socket
file permissions?
What version of the product are you using? On what operating system?
memcached 1.4.9 on an unknown Linux OS (my host...)
Please provide any additional information below.
Original issue reported on code.google.com by [email protected]
on 24 Jan 2009 at 11:38
What steps will reproduce the problem?
1. compile
2. ???
3. profit
Reported on the list - dear self: Don't forget to build test on openbsd,
yeesh. Not detecting some of the new ipv6 variables correctly.
Original issue reported on code.google.com by [email protected]
on 27 Dec 2008 at 9:28
I've been thinking about a "stats settings" that effectively dumps
the settings struct. It helps in those cases where someone is asking
questions and you want to know something about their config.
It also helped to write tests for the -C and -b: arguments that got
messed up specifically (as pointed out by Clint Webb). I was able to
write a simple startup test that verifies that -C properly sets the
CAS setting where we want it, and -b: properly sets the tcp backlog
where we want it.
stats settings, documentation and tests are in my stats_settings
branch and visible here:
http://github.com/dustin/memcached/commit/0a83f5235d754543f602bc1aa67...
The option tests and fixes are here:
http://github.com/dustin/memcached/commit/d038aa38b8bfc4ae5abbe007929...
In introducing these, I noticed that we are a bit hopeful in buffer
sizes when processing stats (as we need to do proper protocol-specific
termination). Overall, I think the stats code may need a bit of work
to be safer, but this particular code is no worse.
Original issue reported on code.google.com by [email protected]
on 18 Mar 2009 at 7:07
the server_stats function allocates a 1024 buffer to hold the stats as it
collects them. A ptr called
pos is used to track the location in the buffer and to write new data into the
buffer. We increment
the pointer as we move along but do not protect against *pos going off the end
of the buffer. See
code below
static char *server_stats(uint32_t (*add_stats)(char *buf, const char *key,
const uint16_t klen, const char *val,
const uint32_t vlen, void *cookie), conn *c,
int *buflen) {
char temp[1024];
char val[128];
char *buf = NULL;
char *pos = temp;
....
vlen = sprintf(val, "%lu", (long)pid);
nbytes = add_stats(pos, "pid", strlen("pid"), val, vlen, (void *)c);
pos += nbytes;
*buflen += nbytes;
Original issue reported on code.google.com by [email protected]
on 14 Mar 2009 at 12:30
What steps will reproduce the problem?
1. memcached jars for java application
2. make connection with memcached server
3. set Key-value pair memcached server
connection successfull but server sends response as Error and that's
console prints log as STDERR
2009-03-06 09:17:24,187 ERROR [STDERR] 2009-03-06 09:17:24.187
2009-03-06 09:17:24,187 ERROR [STDERR]
2009-03-06 09:17:24,187 ERROR [STDERR] INFO
2009-03-06 09:17:24,203 ERROR [STDERR]
2009-03-06 09:17:24,203 ERROR [STDERR]
net.spy.memcached.MemcachedConnection
2009-03-06 09:17:24,203 ERROR [STDERR] :
2009-03-06 09:17:24,203 ERROR [STDERR] Added {QA
sa=jjoshi.asite.asitehq.com/192.168.100.94:11211, #Rops=0, #Wops=0, #iq=0,
topRop=null, topWop=null, toWrite=0, interested=0} to connect queue
2009-03-06 09:17:24,218 ERROR [STDERR] 2009-03-06 09:17:24.203
2009-03-06 09:17:24,218 ERROR [STDERR]
2009-03-06 09:17:24,218 ERROR [STDERR] INFO
2009-03-06 09:17:24,218 ERROR [STDERR]
2009-03-06 09:17:24,218 ERROR [STDERR]
net.spy.memcached.MemcachedConnection
2009-03-06 09:17:24,218 ERROR [STDERR] :
2009-03-06 09:17:24,218 ERROR [STDERR] Connection state changed for
sun.nio.ch.SelectionKeyImpl@f0e58b
how to configure memcache server to send responce as DEBUG...
Original issue reported on code.google.com by [email protected]
on 6 Mar 2009 at 9:56
What steps will reproduce the problem?
1. add "-D ALLOW_SLABS_REASSIGN" to CFLAGS
2. compile
with gcc-3.5 you will see warnings, but it does compile:
slabs.c: In function `do_slabs_reassign':
slabs.c:373: warning: use of cast expressions as lvalues is deprecated
slabs.c:403: warning: use of cast expressions as lvalues is deprecated
but with gcc-4 you will see a compile error:
slabs.c: In function 'do_slabs_reassign':
slabs.c:373: error: invalid lvalue in assignment
slabs.c:403: error: invalid lvalue in assignment
tried with 1.2.6 and 1.2.8. same error.
Original issue reported on code.google.com by [email protected]
on 12 May 2009 at 7:42
In the binary protocol version:
At the end of the function process_bin_stat there is a memset command that
uses strlen on a buffer that is not null-terminated. This causes writes
past the end of the buffer and memcached to malfunction or hang sometimes.
Solution:
1)
Just removing the memset seems to work fine.
or alternatively
2)
Change
memset(subcommand, 0, strlen(subcommand));
To
memset(subcommand, 0, nkey);
process_bin_stat:
.
.
.
} else {
int len = 0;
buf = get_stats(subcommand, nkey, &append_bin_stats, (void *)c, &len);
memset(subcommand, 0, strlen(subcommand));
/* len is set to -1 in get_stats if memory couldn't be allocated */
if (len < 0)
write_bin_error(c, PROTOCOL_BINARY_RESPONSE_ENOMEM, 0);
else if (buf == NULL)
write_bin_error(c, PROTOCOL_BINARY_RESPONSE_KEY_ENOENT, 0);
else
write_and_free(c, buf, len);
}
}
Original issue reported on code.google.com by [email protected]
on 13 Feb 2009 at 10:18
What steps will reproduce the problem?
1. placed the attached prove test (udpBinary.t) into <WORKSPACE_ROOT>/t
2. run the test
3. note that 'select' operations times out while waiting for I/O from the
server and then test
hangs
smacky:memcached elambert$ prove t/udpBinary.t
t/udpBinary....ok 1/12
# Failed test 'got readability'
# in t/udpBinary.t at line 120.
t/udpBinary....NOK 2^C
(NOTE, the attached test is not really ready for prime time as basically all it
does is check that
server has i/o to send back and then reads the i/o if there is some. The test
will be improved to
do more, so probably should not be added to the source tree for the time
being).
What is the expected output? What do you see instead?
The test should not fail waiting on I/O from the server, the test should not
hang.
(Tagging this as high priority since the 1.3.2 release is supposed to be the
official binary
protocol release and probably best that binaryUDP work since ASCII udp works,
but clearly this is
not a regression --since binary was not avail in the 1.2.6-- and as such I
would not fight
downgrading the priority)
Original issue reported on code.google.com by [email protected]
on 25 Mar 2009 at 1:53
Attachments:
Currently we have two cache allocators:
* connection structures
* suffix usage
Currently both of them use a shared pool of resources from all threads, and
we might want to make them thread local. We don't need two implementations
of the same functionality, so we should refactor the code.
I have pushed a proposal for a cache allocator (compatible with libumem if
you have that) on github:
http://github.com/trondn/memcached/tree/cache_alloc
Original issue reported on code.google.com by [email protected]
on 19 Mar 2009 at 11:05
append_bin_stats cast a char pointer into a pointer to a structure, but the
problem is that such a structure needs to be aligned in order to access its
members.
We are currently spooling up a lot of data to send back to the client so we
cannot pad the buffer in order to align the structure. A quick fix is to
fill in a local structure and memcpy it into the stream.
Original issue reported on code.google.com by [email protected]
on 13 Mar 2009 at 7:18
It is not possible to issue a storage command without expecting a message
back (the noreply flag in the textual protocol).
we should create q versions like we did for get.
Original issue reported on code.google.com by [email protected]
on 20 Jan 2009 at 10:46
Just from eyeballing the code, I think the accept_new_conns() function (new
connection throttling) might not work.
accept_new_conns(false) is called by the listen thread when there aren't
enough file descriptors. Later, in conn_close(), the code calls
accept_new_conns(true) since closing a connection releases a file descriptor.
But, there's a sanity check in accept_new_conns(), line 3079...
if (! is_listen_thread())
return;
I haven't written a test or proven it live, but I think that
accept_new_conns(true) never really works because of that check. Meaning
once memcached stops accepting new connections, it never starts accepting
new connections anymore.
Original issue reported on code.google.com by [email protected]
on 10 Apr 2009 at 8:45
The "stats reset" command doesn't clear the data from "stats items". Don't
know if it should?
Original issue reported on code.google.com by [email protected]
on 21 Feb 2009 at 10:35
From [email protected]
Still playing with slabs allocation, I found another strange result.
Storing only one small value in memcached, I end up with this output
for stats slabs:
STAT 1:chunk_size 104
STAT 1:chunks_per_page 10082
STAT 1:total_pages 1
STAT 1:total_chunks 10082
STAT 1:used_chunks 10082
STAT 1:free_chunks 0
STAT 1:free_chunks_end 10081
STAT active_slabs 1
STAT total_malloced 1048528
It is strange that whereas I store only one value, used_chunks report
10082. However, after deleting the value, free_chunks increase to 1,
and used_chunks decrease to 10081. Why are chunks in free_chunks_end
also considered as used_chunks ?
Original issue reported on code.google.com by [email protected]
on 17 Mar 2009 at 9:49
Brad Fitzpatrick did some work on verifying the data being incremented and
decremented as well as the delta parameters.
I've brought it back up to master and have it mostly ready -- just waiting
for review.
http://github.com/dustin/memcached/tree/incr_fix
Original issue reported on code.google.com by [email protected]
on 18 Mar 2009 at 7:11
The textual protocol does not allow stale data to persist in the cache in
case of memory allocation errors. The binary protocol allows it.
e.g:
Textual protocol:
////////////////////////
static void process_update_command(conn *c, token_t *tokens, const size_t
ntokens, int comm, bool handle_cas) {
.
.
.
it = item_alloc(key, nkey, flags, realtime(exptime), vlen+2);
if (it == 0) {
if (! item_size_ok(nkey, flags, vlen + 2))
out_string(c, "SERVER_ERROR object too large for cache");
else
out_string(c, "SERVER_ERROR out of memory storing object");
/* swallow the data line */
c->write_and_go = conn_swallow;
c->sbytes = vlen + 2;
/* Avoid stale data persisting in cache because we failed alloc.
* Unacceptable for SET. Anywhere else too? */
if (comm == NREAD_SET) {
it = item_get(key, nkey);
if (it) {
item_unlink(it);
item_remove(it);
}
}
return;
}
.
.
.
}
Textual protocol:
////////////////////////
int do_store_item(item *it, int comm, conn *c) {
.
.
.
if (comm == NREAD_APPEND || comm == NREAD_PREPEND) {
.
.
new_it = do_item_alloc(key, it->nkey, flags,
old_it->exptime, it->nbytes + old_it->nbytes - 2 /* CRLF */);
if (new_it == NULL) {
/* SERVER_ERROR out of memory */
if (old_it != NULL)
do_item_remove(old_it);
return 0;
}
.
.
.
}
Binary protocol:
////////////////////////
static void process_bin_update(conn *c) {
.
.
.
it = item_alloc(key, nkey, req->message.body.flags,
realtime(req->message.body.expiration), vlen+2);
if (it == 0) {
if (! item_size_ok(nkey, req->message.body.flags, vlen + 2)) {
write_bin_error(c, PROTOCOL_BINARY_RESPONSE_E2BIG, vlen);
} else {
write_bin_error(c, PROTOCOL_BINARY_RESPONSE_ENOMEM, vlen);
}
/* swallow the data line */
c->write_and_go = conn_swallow;
return;
}
.
.
.
}
Binary protocol:
////////////////////////
static void process_bin_append_prepend(conn *c) {
.
.
.
it = item_alloc(key, nkey, 0, 0, vlen+2);
if (it == 0) {
if (! item_size_ok(nkey, 0, vlen + 2)) {
write_bin_error(c, PROTOCOL_BINARY_RESPONSE_E2BIG, vlen);
} else {
write_bin_error(c, PROTOCOL_BINARY_RESPONSE_ENOMEM, vlen);
}
/* swallow the data line */
c->write_and_go = conn_swallow;
return;
}
.
.
.
}
Original issue reported on code.google.com by [email protected]
on 17 Dec 2008 at 6:48
With memcached 1.3.x, for the binary protocol,
incrementing/decrementing a non-number incorrectly gives you a success
response and 0 (numeric 0) value. In the ascii protocol, for
comparison, you get an error "CLIENT_ERROR cannot increment or
decrement non-numeric value".
It looks like the complete_incr_bin() function in memcached.c that
calls add_delta() is ignoring add_delta()'s return value, and also
looks like it's using an uninitialized stack buffer.
Using Dustin's python test framework
(http://github.com/dustin/memcached-test)...
def testIncrNonNumber(self):
"""Test incrementing a non-number value."""
self.mc.set("x", 0, 0, "text")
val, cas = self.mc.incr("x")
print(val) # This prints 0 rather than raising an error.
Partial output from running memcached in -vvv mode...
30: going from conn_read to conn_parse_cmd
<30 Read binary protocol data:
<30 0x80 0x05 0x00 0x01
<30 0x14 0x00 0x00 0x00
<30 0x00 0x00 0x00 0x15
<30 0x00 0x00 0x00 0x00
<30 0x00 0x00 0x00 0x00
<30 0x00 0x00 0x00 0x00
30: going from conn_parse_cmd to conn_nread
incr x 1, 0, -1
> FOUND KEY x
>30 Writing bin response:
>30 0x81 0x05 0x00 0x00
>30 0x00 0x00 0x00 0x00
>30 0x00 0x00 0x00 0x08
>30 0x00 0x00 0x00 0x00
>30 0x00 0x00 0x00 0x00
>30 0x00 0x00 0x00 0x09
Original issue reported on code.google.com by [email protected]
on 13 May 2009 at 12:21
static void usage(void) {
.
.
INDRR_ANY
should be :
INADRR_ANY
Original issue reported on code.google.com by [email protected]
on 4 Dec 2008 at 12:25
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.