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
compatibility).
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 ( http://www.twmacinta.com/myjava/fast_md5.php
) instead of Java's default implementation
(java.security.MessageDigest ) 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 ( http://bleu.west.spy.net/~dustin/projects/memcached/)
. 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
