Java Library + Consistent Hashing

Dustin Sallings dustin at
Thu Nov 15 19:00:22 UTC 2007

On Nov 15, 2007, at 10:34 , Rakesh Rajan wrote:

> 1) How stable is the codebase? Currently I am running Greg's library  
> on the production site. Is Dustin's codebase stable enough to switch  
> in production ? ( I know that I need to do some testing at my end  
> before making the decision. But thought of getting some feedback  
> before writing testcases )

	The 2.0 branch changed a lot of stuff to be multi-protocol.  The  
methods that are there should remain, although more may be added.

	There would be a lot of value in making MemcachedClient an interface  
(it's a bit unfortunate I didn't to begin with), but I don't have any  
short term plans to do it (at least, not in a way that would break  

> 2) Any specific reason on why there is only a synchronous get but  
> not synchronous multiget ( I found only async multiget in the API  
> doc ) ?

	There is both asyncGetBulk and getBulk.

> 3) KetamaHash is the consitent hashing implementation. Looking at  
> the code, I can see that we could use FastMD5 ( 
>  ) instead of Java's default implementation   
> ( ) for better hashing performance.

	I'd probably just use FNV with it.  I added MD5 because that's what  
Ketama does.

> While porting my app to the new library, I found
> 1) Server Weights are missing. Does this mean that all server gets  
> the same weights irrespective of the server's config?

	That's correct.  I don't do any server weighting.  I'm a bit dubious  
of the value of it vs. the complexity of ensuring a good distribution.

	I'm not completely against it, but it feels like it could dirty up  
the API in the simple cases if I'm not careful.  I do try to keep  
everything well-tested as well.

> 2) The set and add API forces to provide expiry date. It would be  
> great to also provide a function that would assume that the TTL  
> ( time to live) is infinite. ( Coz most of the data that I store in  
> memcache is expected to be there always :) )

	Well, the protocol requires it, too.  The part of the spec I quoted  
doesn't mention the zero-behavior, which is as follows:

- <exptime> is expiration time. If it's 0, the item never expires
   (although it may be deleted from the cache to make place for other
   items). If it's non-zero (either Unix time or offset in seconds from
   current time), it is guaranteed that clients will not be able to
   retrieve this item after the expiration time arrives (measured by
   server time).

	I'll update my docs accordingly.

> 3) A small typo in the 'Advanced Usage' section ( 
> . It was specified to use f.cancel () to cancel the FutureTask. The  
> FutureTask API ( 1.6 ) actually expects f.cancel(boolean).

	Ah, thanks.  I suppose I should unit test my documentation, too.  :)

	Thanks for the input.

Dustin Sallings

-------------- next part --------------
An HTML attachment was scrubbed...

More information about the memcached mailing list