apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dirk-Willem van Gulik <di...@webweaving.org>
Subject Re: libketama/apr
Date Wed, 06 Feb 2008 10:38:51 GMT

On Feb 6, 2008, at 9:03 AM, Paul Querna wrote:

> To use libketama, you should just be able to use this callback  
> function in apr_memcache trunk, to do server selection:
...
> If you need any other callbacks added, just let us know and we can  
> look into getting them into trunk.  I would like to make  
> apr_memcache behaviors more plugable, rather than people having to  
> patch it.....

Getting there. Not found anything mayor - though it may make perfect  
sense to add an extra level of config - i.e. be able to pass config  
information (i.e. both the ssl and my module now have a fair bit of  
setup in common) and secondly be able to pass something like an iovec  
(as this is easily made form a bucket brigade) or similar as the  
baton. I.e. get closer to a zero copy of at least the payload itself.

> On libketama, you need to be aware of issues with flapping nodes  
> and cache consistency issues... Its definitely something I wouldn't  
> want apr_memcache using by default.

Agreed. Though some of this is a bit out of scope of ketama/apache -  
and more tied to management ? Or is there a fundamentally better  
approach to accomplish same* ?

Ultimately I think it would make perfect sense to have a decent  
robust/consistent hash in APR itself (and support; like crc32, mvec- 
hashes) - as there are more places we can use this.

Dw.

*: hash out a cache across multiple servers, disk-spindles, log- 
files, ldap-backends, etc  without causing too much
    havoc when one (temporarily) dies.

Mime
View raw message