Re: new website
Hey guys, Thanks for passing those along. I fixed them. If anyone sees any issues with the incubator redirects let me know (they seem to work for me). One weird thing is that our KEYS file is still in SVN. Perhaps that should be moved to the git repo? Neha--as Johan mentions two of your presentations are no longer accessible on the wiki, maybe there is another copy somewhere on the web or maybe you have a copy you could upload? -Jay On Fri, Dec 14, 2012 at 4:40 PM, David Arthur wrote: > On 12/14/12 4:30 PM, Jay Kreps wrote: > >> http://kafka.apache.org/ >> >> I will set up redirects from the old to the new. >> >> If folks could sanity check the links, email addresses, english, and so on >> that would be swell. >> >> -Jay >> >> Small nit - Flume has graduated and has a new webpage > http://flume.apache.org/ > >
review board?
Neha mentioned that it is possible to get review board setup and maintained by apache infra. We are pretty code-review centric, and I think review board is a lot easier to use then trying to map random comments in JIRA back to lines of code. How would people feel about using review board? A few other questions: Will this setup work with git? Is it possible to get patches that are attached in JIRA automatically entered in review board? If we have to do it manually it might be too annoying... Are there any examples of projects using this so we can see how they do it? Cheers, -Jay
[jira] [Resolved] (KAFKA-673) Broker recovery check logic is reversed
[ https://issues.apache.org/jira/browse/KAFKA-673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay Kreps resolved KAFKA-673. - Resolution: Fixed > Broker recovery check logic is reversed > --- > > Key: KAFKA-673 > URL: https://issues.apache.org/jira/browse/KAFKA-673 > Project: Kafka > Issue Type: Bug >Affects Versions: 0.8 >Reporter: Jay Kreps >Assignee: Jay Kreps >Priority: Critical > Fix For: 0.8 > > Attachments: KAFKA-673.patch > > > We are currently running recovery when there IS a clean shutdown and not > recovering when there isn't. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (KAFKA-374) Move to java CRC32 implementation
[ https://issues.apache.org/jira/browse/KAFKA-374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay Kreps resolved KAFKA-374. - Resolution: Fixed Assignee: Jay Kreps Checked in the java version. > Move to java CRC32 implementation > - > > Key: KAFKA-374 > URL: https://issues.apache.org/jira/browse/KAFKA-374 > Project: Kafka > Issue Type: New Feature > Components: core >Affects Versions: 0.8 >Reporter: Jay Kreps >Assignee: Jay Kreps >Priority: Minor > Labels: newbie > Attachments: KAFKA-374-draft.patch, KAFKA-374.patch > > > We keep a per-record crc32. This is fairly cheap algorithm, but the java > implementation uses JNI and it seems to be a bit expensive for small records. > I have seen this before in Kafka profiles, and I noticed it on another > application I was working on. Basically with small records the native > implementation can only checksum < 100MB/sec. Hadoop has done some analysis > of this and replaced it with a Java implementation that is 2x faster for > large values and 5-10x faster for small values. Details are here HADOOP-6148. > We should do a quick read/write benchmark on log and message set iteration > and see if this improves things. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
