Well, I guess what I was thinking is that since we have the long timeout on the vote anyway, no reason not to call the vote now, should anything else pop up we can cancel the vote.
-Jay On Wed, Feb 18, 2015 at 4:04 PM, Jun Rao <j...@confluent.io> wrote: > Well, KAFKA-1952 only introduces high CPU overhead if the number of > partitions in a fetch request is high, say more than a couple of hundreds. > So, it may not show up in every installation. For example, if you have 1000 > leader replicas in a broker, but have a 20 node cluster, each replica fetch > request is only going to include about 50 partitions. Since there is a bit > of overhead running a release, I was hoping to collect some more feedback > from people trying the 0.8.2.0 release who may not be affected by this > issue. But I agree that we don't need to wait for too long. > > Thanks, > > Jun > > On Wed, Feb 18, 2015 at 2:13 PM, Jay Kreps <jay.kr...@gmail.com> wrote: > > > Does it make sense to wait, I don't think people will upgrade without the > > patched version and I think we should release it to unblock people. > > > > -Jay > > > > On Wed, Feb 18, 2015 at 1:43 PM, Jun Rao <j...@confluent.io> wrote: > > > > > We have fixed the issue in KAFKA-1952. We will wait for a few more days > > to > > > see if any new issue comes up. After that, we will do an 0.8.2.1 > release. > > > > > > Thanks, > > > > > > Jun > > > > > > On Fri, Feb 13, 2015 at 3:28 PM, Jay Kreps <jay.kr...@gmail.com> > wrote: > > > > > > > Hey all, > > > > > > > > We found an issue in 0.8.2 that can lead to high CPU usage on brokers > > > with > > > > lots of partitions. We are working on a fix for this. You can track > > > > progress here: > > > > https://issues.apache.org/jira/browse/KAFKA-1952 > > > > > > > > I would recommend holding off on upgrading to 0.8.2 until we have a > fix > > > for > > > > this issue. Sorry for the inconvenience. > > > > > > > > -Jay > > > > > > > > > >
