By moving away from spins to explicit synchronization we managed to squish the bug we have been seeing. I also moved us to use volatiles in RWCC just because. We should probably ship with this patch once it's committed.
On Wed, Jun 23, 2010 at 12:27 PM, Todd Lipcon <t...@cloudera.com> wrote: > On Tue, Jun 22, 2010 at 9:05 PM, Stack <st...@duboce.net> wrote: > >> On Tue, Jun 22, 2010 at 6:35 PM, Todd Lipcon <t...@cloudera.com> wrote: >> > >> > Quick update on the development branch 0.89.20100621. >> > >> >> (Todd you want to explain the version number or do you want me to?) >> >> >> > I think the following patches still need to go in: >> > - HBASE-2767 (failed tests building with HDFS-1209) >> >> Reviewed. >> >> Committed > > >> > - HBASE-2729 (fix bug when flush hits IOE) >> >> Please paste patch into issue so can review (review.hbase.org is down) >> >> > Stack reviewed and I committed > > >> >> > - I'd also like to disable the TestAcidGuarantees test in this branch, >> since >> > that is a known bug. >> >> Done > >> >> Grand. >> >> > - I'd like to commit a short KNOWN_BUGS file which describes a few of the >> > open issues that we're currently working on. Certainly doesn't have to be >> > exhaustive list of all open JIRAs, but just a few things that users may >> run >> > into. >> > >> >> Yeah. Just call out the biggies and refer use to the short list >> (ahem) of other issues we have against next major release. >> >> Done > >> >> > Some performance issues were raised during testing at StumbleUpon -- any >> > luck figuring those out, Ryan/Stack? It would be good to address them for >> > the dev release, since it sounds like the RS barely makes progress when >> this >> > bug is triggered. >> > >> >> >> Yeah, its a beaut. Sucks all resources for some period of time until >> it gets over first flush then its good to go for a while at least. >> Still trying to figure it. >> >> > This one is still mysterious - it happens a lot over at StumbleUpon but I > haven't been able to repro on my cluster. I put it in the known bugs list. > > >> >> > Given the above, I'd like to see if we can get the above two jiras >> reviewed >> > and committed later tonight, and I'll try to roll a release candidate >> before >> > I go to sleep. I think the correct way to release in this maven land is >> to >> > simply do an svn export and vote on that, and then separately do an >> > assembly:assembly tar as a binary release artifact (since assembly tar >> > doesn't include unpacked source, etc). >> > >> >> Why not just vote on the assembly? Thats what we'd run? If you do a >> site before assembly:assembly, you'll even have docs (mvn install site >> assembly;assembly). The source is there to review if wanted. Doing >> an svn export will have to build ourselves. >> >> > Doug says: > "Yes, as an open-source foundation, ASF projects fundamentally produce > source-code releases. Binaries are optional, sources not. > > Overall this sounds like a good plan. An ASF release needn't be top-quality > and bug-free, but it needs to be voted on. When voting on a release a > primary concern should be that it contains properly licensed code. Voters > may additionally wish releases to have a certain level of quality, e.g., > more for final releases than snapshot releases, but that's not a requirement > of every ASF release." > > So until we figure out a way to make a mvn assembly that is > self-hosting/recompilable, let's just vote an an svn export tarball. Of > course right next to it will be a "bin" tarball (which includes src jar, > bin, docs, etc) > > Given that I think we have everything in place, I'm going to kick off some > new cluster tests here and start a vote thread. > > -Todd > > -- > Todd Lipcon > Software Engineer, Cloudera >
