apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Berlin <dber...@dberlin.org>
Subject apr_memcache and timeouts
Date Fri, 11 Aug 2006 00:57:58 GMT
Hi guys (please cc me, i'm not surprised to dev@apr),

apr_memcache in apr-util trunk uses apr_socket_sendv in
storage_cmd_write without ever bothering to check whether the amount
written was the amount we were trying to send.

It also sets a timeout on the socket at a low value, 1 second, which,
as the docs for apr_socket_sendv say, causes the socket to act as if
it was nonblocking.

This means when you try to do an apr_memcache_add with a "large data
size", say, 100k or more, apr_socket_sendv sends less than the total
amount before returning and setting written and returning APR_SUCCESS.
apr_memcache assumes that because the sendv returned APR_SUCCESS, it wrote
the whole thing.

It then sits there waiting for the server's response, but the server
is waiting for apr_memcache to send the rest of the data.

The apr_memcache side times out waiting for the socket read of the
response that will never come, and then considers it an error and
disables the server for 5 seconds, until something tries to add a key
with a large amount of data, and we go around the circle again.

Really, if you want to continue to use socket_sendv, there needs to be
a loop around the send that moves through the pieces of the iovec
while written != sum{k=1..n}{iovec[k].len}.

Either that, or not using sendv as the mechanism for adds.

Theoretically, the other sendv uses have the same problem, it's just
highly unlikely that you will hit it because they are sending so
little data (IE "get <key>" commands), unless you have very very large
keys.

In my copy, i just made it blocking for now

(for the curious, i am using apr_memcache to do caching of svn fulltexts
for gcc's repository)

--Dan

Mime
View raw message