<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Nov 15, 2007, at 10:34 , Rakesh Rajan wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; ">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 )<span class="Apple-converted-space">&nbsp;</span></span></blockquote><div><br class="webkit-block-placeholder"></div><div><span class="Apple-tab-span" style="white-space:pre">        </span>The 2.0 branch changed a lot of stuff to be multi-protocol. &nbsp;The methods that are there should remain, although more may be added.</div><div><br class="webkit-block-placeholder"></div><div><span class="Apple-tab-span" style="white-space:pre">        </span>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).<br class="webkit-block-placeholder"></div><div><br class="webkit-block-placeholder"></div><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; ">2) Any specific reason on why there is only a synchronous<span class="Apple-converted-space">&nbsp;</span><i>get<span class="Apple-converted-space">&nbsp;</span></i>but not synchronous<span class="Apple-converted-space">&nbsp;</span><i>multiget<span class="Apple-converted-space">&nbsp;</span></i>( I found only async<span class="Apple-converted-space">&nbsp;</span><i>multiget<span class="Apple-converted-space">&nbsp;</span></i>in the API doc ) ?</span></blockquote><div><br class="webkit-block-placeholder"></div><div><span class="Apple-tab-span" style="white-space:pre">        </span>There is both asyncGetBulk and getBulk.<br class="webkit-block-placeholder"></div><br><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; ">3) KetamaHash is the consitent hashing implementation. Looking at the code, I can see that we could use FastMD5 (<span class="Apple-converted-space">&nbsp;</span><a href="http://www.twmacinta.com/myjava/fast_md5.php">http://www.twmacinta.com/myjava/fast_md5.php</a><span class="Apple-converted-space">&nbsp;</span>) instead of Java's default implementation&nbsp; (java.security.MessageDigest ) for better hashing performance.</span></blockquote><div><br class="webkit-block-placeholder"></div><div><span class="Apple-tab-span" style="white-space:pre">        </span>I'd probably just use FNV with it. &nbsp;I added MD5 because that's what Ketama does.</div><div><br class="webkit-block-placeholder"></div><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; ">While porting my app to the new library, I found<span class="Apple-converted-space">&nbsp;</span><br><br>1) Server Weights are missing. Does this mean that all server gets the same weights irrespective of the server's config?</span></blockquote><div><br class="webkit-block-placeholder"></div><div><span class="Apple-tab-span" style="white-space:pre">        </span>That's correct. &nbsp;I don't do any server weighting. &nbsp;I'm a bit dubious of the value of it vs. the complexity of ensuring a good distribution.</div><div><br class="webkit-block-placeholder"></div><div><span class="Apple-tab-span" style="white-space:pre">        </span>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. &nbsp;I do try to keep everything well-tested as well.<br class="webkit-block-placeholder"></div><div><br class="webkit-block-placeholder"></div><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; ">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 :) )<span class="Apple-converted-space">&nbsp;</span></span></blockquote><div><br class="webkit-block-placeholder"></div><div><span class="Apple-tab-span" style="white-space:pre">        </span>Well, the protocol requires it, too. &nbsp;The part of the spec I quoted doesn't mention the zero-behavior, which is as follows:</div><div><br class="webkit-block-placeholder"></div><div><div>- &lt;exptime&gt; is expiration time. If it's 0, the item never expires</div><div>&nbsp;&nbsp;(although it may be deleted from the cache to make place for other</div><div>&nbsp;&nbsp;items). If it's non-zero (either Unix time or offset in seconds from</div><div>&nbsp;&nbsp;current time), it is guaranteed that clients will not be able to</div><div>&nbsp;&nbsp;retrieve this item after the expiration time arrives (measured by</div><div>&nbsp;&nbsp;server time).</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre">        </span>I'll update my docs accordingly.</div><div><br class="webkit-block-placeholder"></div></div><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; ">3) A small typo in the 'Advanced Usage' section (<span class="Apple-converted-space">&nbsp;</span><a href="http://bleu.west.spy.net/~dustin/projects/memcached/">http://bleu.west.spy.net/~dustin/projects/memcached/</a>). It was specified to use f.cancel () to cancel the FutureTask. The FutureTask API ( 1.6 ) actually expects f.cancel(boolean).<br></span></blockquote></div><div><br class="webkit-block-placeholder"></div><div><span class="Apple-tab-span" style="white-space:pre">        </span>Ah, thanks. &nbsp;I suppose I should unit test my documentation, too. &nbsp;:)<br class="webkit-block-placeholder"></div><div><br class="webkit-block-placeholder"></div><div><span class="Apple-tab-span" style="white-space:pre">        </span>Thanks for the input.<br class="webkit-block-placeholder"></div><br><div> <span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><div style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><div>--&nbsp;</div><div>Dustin Sallings</div></div><br class="Apple-interchange-newline"></span> </div><br></body></html>