Grokbase Groups HBase dev June 2010
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 wrote:
On Tue, Jun 22, 2010 at 9:05 PM, Stack wrote:
On Tue, Jun 22, 2010 at 6:35 PM, Todd Lipcon 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)

- HBASE-2729 (fix bug when flush hits IOE)
Please paste patch into issue so can review ( 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.
- 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
Yeah.  Just call out the biggies and refer use to the short list
(ahem) of other issues we have against next major release.

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 Lipcon
Software Engineer, Cloudera

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 9 of 10 | next ›
Discussion Overview
groupdev @
categorieshbase, hadoop
postedJun 23, '10 at 1:36a
activeJun 23, '10 at 11:36p



site design / logo © 2022 Grokbase