apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Holsman <li...@holsman.net>
Subject Re: svn commit: r329089 - in /apr/apr-util/trunk: build.conf include/apr_memcache.h memcache/ memcache/apr_memcache.c
Date Fri, 28 Oct 2005 23:25:21 GMT
William A. Rowe, Jr. wrote:
> Paul Querna wrote:
>> Joe Orton wrote:
>>
>>> - apr_memcache_hash's data_len argument, apr_memcache_conn_t.blen , 
>>> storage_cmd_write's *_size  arguments are all apr_uint32_t and look 
>>> like they should be apr_size_t, any reason why that is?
>>
>> Ah, now I remember why.  The memcached protocol states that these data
>> lengths are all unsigned 32bit ints.  So, they can never hold values
>> larger, or the server will not understand.
> 
> So, we violate a basic apr design principal for an oddball service that we
> are seeking to support?  Or return APR_EINVAL when someone tries to set
> aside 10GB?  (This is a rather funny quibble when you consider how horrid
> using an external socket-cached data store to set aside 10GB for 'quick
> access' later on ;-)

first, can you stop with the 'oddball' comments. If you don't think 
memcached is useful, fine. but for others it serves a need which isn't 
there in the current apr/util family, and that is a distributed/shared 
cache.
memcached has been around for years, has a large user base, and plays a 
part in several large corporations, while you might not find this 
useful, others do.

as for the parameter issue, from what I remember the general APR ethos 
is garbage in garbage out.
We don't do parameter checking, in most of the apis we have, from what I 
recall. and making it a different field size will cause surprise for 
users when they try to cache 2^32+1 bytes and it fails. better to tell 
the user this is exactly how much you can do straight off and let the 
compiler issue the warning instead of doing it at runtime.

It also sets the perception that this is for caching *smallish* things, 
not 700M ISOs.

> 
> If apr-util is designed to be a pluggable abstraction layer, and we all
> concur that
> 
>   char *buf;
>   apr_size_t *bufsize;
>   apr_dosomething(*buf, &bufsize);
> 
> is our normalized style, obviously this patch was correct, irrespective
> of whatever this particular backend cache supports.
> 
> FYI - why apr_memcache?  Unless it's either an in-memory cache, or some
> cache virtualized by page-fault retrieval, this is definately misnamed,
> or beholden to one oddball external project.
> 
apr_memcache is a interface to a single-process memory cache.
It also has the advanced feature of segregating by the key value to a 
set of single process memory caches (cachee?), which can be distributed 
across a set of machines. (and provide a common cache across a entire 
server farm)

so the 'mem' stands for memory as it doesn't use disk (similar to 
mod_mem_cache and mod_disk_cache)

and the 'cache' stands for non-persistent, as there is no guarantee that 
the data you put in there 5 seconds ago will still be there the next 
time you ask.

we could call it apr_dist_mem_cache if you prefer ?

> Bill
> 


Mime
View raw message