----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/31040/#review72482 -----------------------------------------------------------
Minor question about a check that got removed, but otherwise LGTM. core/src/main/scala/kafka/server/RequestPurgatory.scala <https://reviews.apache.org/r/31040/#comment118542> The if (t.satisfied.get) return false part got removed when you converted checkAndMaybeAdd -> add. Is the assumption that adding the request for watch on all the keys is fast enough that it's unlikely to get satisfied in that time? If there is a decent chance, is it better to keep the request off more keys' watch lists by adding that check back in, or will it not have a substantial impact on the extra state this patch causes the purgatory to hold on to? I think the current code probably makes more sense, but I want to check since, given the CPU usage problem wasn't identified in the original patch it seems we previously thought the check was worth it. - Ewen Cheslack-Postava On Feb. 14, 2015, 1:52 a.m., Jun Rao wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/31040/ > ----------------------------------------------------------- > > (Updated Feb. 14, 2015, 1:52 a.m.) > > > Review request for kafka. > > > Bugs: kafka-1952 > https://issues.apache.org/jira/browse/kafka-1952 > > > Repository: kafka > > > Description > ------- > > KAFKA-1952; High CPU Usage in 0.8.2 release > > > Diffs > ----- > > core/src/main/scala/kafka/server/RequestPurgatory.scala > 9d76234bc2c810ec08621dc92bb4061b8e7cd993 > > Diff: https://reviews.apache.org/r/31040/diff/ > > > Testing > ------- > > > Thanks, > > Jun Rao > >
