> On Feb. 14, 2015, 5 a.m., Ewen Cheslack-Postava wrote: > > core/src/main/scala/kafka/server/RequestPurgatory.scala, line 136 > > <https://reviews.apache.org/r/31040/diff/1/?file=864054#file864054line136> > > > > 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.
That's a good point. Will add the extra check. - Jun ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/31040/#review72482 ----------------------------------------------------------- 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 > >
