[AOLSERVER] nsmemcache driver issue with data over 2kb
Sep Ng
I've been trying to use nsmemcache and integrate it with aolserver but
I noticed that there's this bug where if you retrieve data over 2kb,
the data gets truncated. After inspection, it looks like it's because
the buffer size allocated when reading the contents via Ns_SockRecv is
not adequate. I wonder if anyone has come across this partcular
issue.
I modified nsmemcache to accept a parameter setting from aolserver to
define a custom buffer size. I wasn't entirely sure where the code
submissions were. I'd be more than happy to send the changes
upstream, hope someone can point me the way because the contributing
patches section on the aolserver website was kind of confusing.
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to <list...@listserv.aol.com> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
Sep Ng
needs it.
--- nsmemcache.c.4.5.1 2010-08-30 06:56:06.000000000 +0800
+++ nsmemcache.c 2010-08-30 11:19:20.000000000 +0800
@@ -50,6 +50,7 @@
#define MC_SERVER_DELETED 2 /* Server is not used
anymore */
int Ns_ModuleVersion = 1;
+int bufsize = BUFSIZE;
typedef struct mc_conn_t
{
@@ -184,6 +185,18 @@
key = Ns_SetValue(set, i);
mc_server_add(mc, mc_server_create(key, 0, 0));
Ns_Log(Notice, "nsmemcache: added %s", key);
+ } else if (!strcasecmp(key, "bufsize")) {
+ key = Ns_SetValue(set, i);
+
+ if (key != NULL) {
+
+ if(sscanf(key,"%d",&bufsize) == -1) {
+ //Reset the value to default buffer size.
+ bufsize = BUFSIZE;
+ } else {
+ Ns_Log(Notice,"nsmemcache: setting buffer size to
%d", bufsize);
+ }
+ }
}
}
// For AOL 4.0.10
@@ -664,7 +677,7 @@
return -1;
}
- rc = mc_conn_read(conn, BUFSIZE, 1, &line);
+ rc = mc_conn_read(conn, bufsize, 1, &line);
if (rc <= 0) {
mc_conn_free(conn);
mc_server_dead(mc, ms);
@@ -725,7 +738,7 @@
/* VALUE <key> <flags> <bytes> [cas unique]\r\n<data block>\r\nEND
\r\n */
- rc = mc_conn_read(conn, BUFSIZE, 1, &line);
+ rc = mc_conn_read(conn, bufsize, 1, &line);
if (rc <= 0 || line == NULL) {
mc_conn_free(conn);
mc_server_dead(mc, ms);
@@ -817,7 +830,7 @@
return -1;
}
- rc = mc_conn_read(conn, BUFSIZE, 1, &line);
+ rc = mc_conn_read(conn, bufsize, 1, &line);
if (rc <= 0) {
mc_conn_free(conn);
mc_server_dead(mc, ms);
@@ -876,7 +889,7 @@
/* <value>\r\n */
- rc = mc_conn_read(conn, BUFSIZE, 1, &line);
+ rc = mc_conn_read(conn, bufsize, 1, &line);
if (rc <= 0) {
mc_conn_free(conn);
mc_server_dead(mc, ms);
@@ -929,7 +942,7 @@
/* VERSION <version>\r\n */
- rc = mc_conn_read(conn, BUFSIZE, 1, &line);
+ rc = mc_conn_read(conn, bufsize, 1, &line);
if (rc <= 0) {
mc_conn_free(conn);
mc_server_dead(mc, ms);
@@ -994,7 +1007,7 @@
return -1;
}
- rc = mc_conn_read(conn, BUFSIZE, 1, &line);
+ rc = mc_conn_read(conn, bufsize, 1, &line);
if (rc <= 0) {
mc_conn_free(conn);
mc_server_dead(mc, ms);
@@ -1048,10 +1061,10 @@
// Read trailing \r\n and END\r\n
if (strncmp(conn->ds.string, "\r\n", 2)) {
- rc = mc_conn_read(conn, BUFSIZE, 0, &line);
+ rc = mc_conn_read(conn, bufsize, 0, &line);
}
if (strstr(conn->ds.string, "END\r\n") == NULL) {
- rc = mc_conn_read(conn, BUFSIZE, 0, &line);
+ rc = mc_conn_read(conn, bufsize, 0, &line);
}
mc_conn_put(conn);
return 1;
On Aug 31, 5:43�am, Sep Ng <thejackschm...@GMAIL.COM> wrote:
> Hi,
>
> I've been trying to use nsmemcache and integrate it with aolserver but
> I noticed that there's this bug where if you retrieve data over 2kb,
> the data gets truncated. �After inspection, it looks like it's because
> the buffer size allocated when reading the contents via Ns_SockRecv is
> not adequate. �I wonder if anyone has come across this partcular
> issue.
>
> I modified nsmemcache to accept a parameter setting from aolserver to
> define a custom buffer size. �I wasn't entirely sure where the code
> submissions were. �I'd be more than happy to send the changes
> upstream, hope someone can point me the way because the contributing
> patches section on the aolserver website was kind of confusing.
>
> --
> AOLserver -http://www.aolserver.com/
>
> To Remove yourself from this list, simply send an email to <lists...@listserv.aol.com> with the
Dossy Shiobara
still relevant. If it is, I'll merge it in.
On 8/31/10 7:17 PM, Sep Ng wrote:
> Okay, I guess I'll simply post the diff patch here for anyone who
> needs it.
--
Dossy Shiobara | do...@panoptic.com | http://dossy.org/
Panoptic Computer Network | http://panoptic.com/
"He realized the fastest way to change is to laugh at your own
folly -- then you can let go and quickly move on." (p. 70)
Sep Ng
it's still relevant. I'll post a new diff if needed.
On Sep 4, 10:55�am, Dossy Shiobara <do...@PANOPTIC.COM> wrote:
> �After you test the latest code from Majid, determine if your patch is
> still relevant. �If it is, I'll merge it in.
>
> On 8/31/10 7:17 PM, Sep Ng wrote:
>
> > Okay, I guess I'll simply post the diff patch here for anyone who
> > needs it.
>
> --
> Dossy Shiobara � � � � � � �| do...@panoptic.com |http://dossy.org/
> Panoptic Computer Network � |http://panoptic.com/
> � "He realized the fastest way to change is to laugh at your own
> � � folly -- then you can let go and quickly move on." (p. 70)
>
> --
> AOLserver -http://www.aolserver.com/
>
> To Remove yourself from this list, simply send an email to <lists...@listserv.aol.com> with the
Sep Ng
think my patch is relevant anymore.
Cheers.
Dossy Shiobara
Thanks for confirming.
On 9/5/10 7:00 PM, Sep Ng wrote:
> I have run some tests and Majid's changes fixed the bug, so I don't
> think my patch is relevant anymore.
>
> Cheers.
--
Dossy Shiobara | do...@panoptic.com | http://dossy.org/
Panoptic Computer Network | http://panoptic.com/
"He realized the fastest way to change is to laugh at your own
folly -- then you can let go and quickly move on." (p. 70)
--