cal mode
> the master does not start fast enough it seems, and the RS is too
> impatient).
>
>
> +1
>
> -- Lars
>
>
>
>
> From: Stack
> To: HBase Dev List
> Sent: Friday, April 5, 2013 9:53 PM
> Subject: Re: VOTE: hbase-0.9
gt; But in the end the RS started up anyway. Again, just a nit (in local mode
> > the master does not start fast enough it seems, and the RS is too
> > impatient).
> >
> >
> > +1
> >
> > -- Lars
> >
> >
> >
> > __________
; Sent: Friday, April 5, 2013 9:53 PM
> Subject: Re: VOTE: hbase-0.95RC1, the second "Development" Series Release
> is available [WAS -> VOTE: hbase-0.95.0RC0, the first "Developer Release"
> release candidate is available for download and vote]
>
> Any ch
Stack
To: HBase Dev List
Sent: Friday, April 5, 2013 9:53 PM
Subject: Re: VOTE: hbase-0.95RC1, the second "Development" Series Release is
available [WAS -> VOTE: hbase-0.95.0RC0, the first "Developer Release" release
candidate is available for download and vote]
Any c
Any chance of a few more +1s here so I can push this out? Thanks all.
St.Ack
On Tue, Apr 2, 2013 at 10:12 PM, Stack wrote:
> Here is the second 0.95.0 release candidate. Should we put this out as
> 0.95.0? Please
> vote by friday, April 5th.
>
> See the refguide [1] for definition of what a
One thing I don't understand is why there is noticeable difference in
performance between 0.95.0 and trunk.
I think their code should be very close to each other.
On Thu, Apr 4, 2013 at 8:20 AM, Jean-Marc Spaggiari wrote:
> I ran the performances tests against 0.95.0RC1.
>
> While filteredScan,
I ran the performances tests against 0.95.0RC1.
While filteredScan, read and writes got nice improvements (18% faster
for the reads), scans seems to be negatively impacted (32% slower for
scanRange100).
Results are there:
http://www.spaggiari.org/media/blogs/hbase/pdf/performances_20130404.pdf
I
I think that sounds good.
On Wednesday, April 3, 2013, Stack wrote:
> On Wed, Apr 3, 2013 at 10:55 AM, Andrew Purtell
> >
> wrote:
>
> > Then what if we do not provide native binary convenience artifacts and
> > instead print an INFO level log message, should they be missing, which
> > points to
On Wed, Apr 3, 2013 at 10:55 AM, Andrew Purtell wrote:
> Then what if we do not provide native binary convenience artifacts and
> instead print an INFO level log message, should they be missing, which
> points to a book chapter on compiling and installing them?
>
>
Yes. For now, I could just fil
Then what if we do not provide native binary convenience artifacts and
instead print an INFO level log message, should they be missing, which
points to a book chapter on compiling and installing them?
On Wed, Apr 3, 2013 at 10:43 AM, Stack wrote:
> On Wed, Apr 3, 2013 at 10:11 AM, Todd Lipcon
On Wed, Apr 3, 2013 at 10:11 AM, Todd Lipcon wrote:
> Shipping the native libs is difficult anyway, because the artifacts will
> depend on the particular architecture/OS that you compile on. (eg if you
> compile on Ubuntu 12.04, it'll be useless on RHEL6 or vice versa).
>
> If we want them to wor
Shipping the native libs is difficult anyway, because the artifacts will
depend on the particular architecture/OS that you compile on. (eg if you
compile on Ubuntu 12.04, it'll be useless on RHEL6 or vice versa).
If we want them to work out of the box, we'd need to cross-compile or
otherwise do th
I think Ram's JIRA should be HBASE-7962
FYI
On Wed, Apr 3, 2013 at 10:07 AM, ramkrishna vasudevan <
ramkrishna.s.vasude...@gmail.com> wrote:
> Stack for the native libs not found i raised a JIRA recently. I tried
> figuring out the problem but left it half way.
> I dont remember the JIRA id no
Stack for the native libs not found i raised a JIRA recently. I tried
figuring out the problem but left it half way.
I dont remember the JIRA id now.
Regards
Ram
On Wed, Apr 3, 2013 at 10:08 PM, Stack wrote:
> On Wed, Apr 3, 2013 at 1:02 AM, Elliott Clark wrote:
>
> > +1
> >
> > Verified the
I was looking at the maven dependencies in
https://repository.apache.org/content/repositories/snapshots/org/apache/hbase/hbase/0.95.0-hadoop2-SNAPSHOT/hbase-0.95.0-hadoop2-20130402.025905-1.pom
I would expect (I may be wrong) that it's the one to be used when you build
a java application on top of
On Wed, Apr 3, 2013 at 1:02 AM, Elliott Clark wrote:
> +1
>
> Verified the gpg signature for hadoop2 and source tar balls.
> Spun up a local instance.
> Created tables. Put data, got data
> Ran TestAcidGuarantees for about 2 hours.
> Tried an online schema change while running test acid. (seemed
On Wed, Apr 3, 2013 at 9:04 AM, Nicolas Liochon wrote:
> If I'm not wrong, the pom.xml for hbase-hadoop2 gets the hadoop1-compat
> because hadoop.profile=1.0 by default. If so, it means that a user must
> specify it from it's maven build line as well (i.e. having the dependency
> on hbase-hadoop2
DEBUG is lower than INFO. Edit log4j.properties to set the loglevel for
org.apache.hadoop.hbase to INFO.
On Wed, Apr 3, 2013 at 7:33 AM, Jean-Marc Spaggiari wrote:
> Tests in progress...
>
> Lru is pretty verbose...
>
> jmspaggi@hbasetest:~/hbase/hbase-0.95.0-hadoop1$ cat
> logs/hbase-jmspaggi-
If I'm not wrong, the pom.xml for hbase-hadoop2 gets the hadoop1-compat
because hadoop.profile=1.0 by default. If so, it means that a user must
specify it from it's maven build line as well (i.e. having the dependency
on hbase-hadoop2 is not enough).
Is this voluntary? May be it should be documen
On Wed, Apr 3, 2013 at 7:33 AM, Jean-Marc Spaggiari
wrote:
> Tests in progress...
>
> Lru is pretty verbose...
AFAIK it's always been like that, and it's worse when you have a small
block cache that you're banging on like in your case.
>
> jmspaggi@hbasetest:~/hbase/hbase-0.95.0-hadoop1$ cat
> l
Tests in progress...
Lru is pretty verbose...
jmspaggi@hbasetest:~/hbase/hbase-0.95.0-hadoop1$ cat
logs/hbase-jmspaggi-master-hbasetest.log | wc
53518 938381 9515387
jmspaggi@hbasetest:~/hbase/hbase-0.95.0-hadoop1$ cat
logs/hbase-jmspaggi-master-hbasetest.log | grep LruBlockCache | wc
50163
+1
Verified the gpg signature for hadoop2 and source tar balls.
Spun up a local instance.
Created tables. Put data, got data
Ran TestAcidGuarantees for about 2 hours.
Tried an online schema change while running test acid. (seemed to work but
caused a huge drop in throughput)
Created a snapshot whi
Here is the second 0.95.0 release candidate. Should we put this out as
0.95.0? Please
vote by friday, April 5th.
See the refguide [1] for definition of what a "Development" Series Release
is (or read below where we call it a 'developer release"). In short, it is
a preview release, not for produ
J2MD, the nifty French-ish duo, at your service.
J-D
On Tue, Apr 2, 2013 at 1:28 PM, Stack wrote:
> On Tue, Apr 2, 2013 at 11:20 AM, Jean-Daniel Cryans
> wrote:
>
>> -1
>>
>> The hbase-common-0.95.0-hadoop1.jar has a tainted hbase-default.xml
>> (like J-M saw):
>>
>>hbase.rootdir
>> fil
On Tue, Apr 2, 2013 at 11:20 AM, Jean-Daniel Cryans wrote:
> -1
>
> The hbase-common-0.95.0-hadoop1.jar has a tainted hbase-default.xml
> (like J-M saw):
>
>hbase.rootdir
> file:///tmp/hbase-stack/hbase
> ...
> hbase.tmp.dir
>
> /var/folders/bp/2z1cykc92rs6j24251cg__phgp/T//hbase-s
-1
The hbase-common-0.95.0-hadoop1.jar has a tainted hbase-default.xml
(like J-M saw):
hbase.rootdir
file:///tmp/hbase-stack/hbase
...
hbase.tmp.dir
/var/folders/bp/2z1cykc92rs6j24251cg__phgp/T//hbase-stack
Not sure if there are others.
J-D
On Tue, Apr 2, 2013 at 11:07 AM, S
Some followup:
+ I pushed up this release to maven repository as SNAPSHOTs. Would be
interested if these published artifacts are useable at all; in particular,
does our new hbase-client 'work' (i.e. does it make it so you can go
against hbase cluster w/o having to put the world of hbase on your
I also searched for any reference to this directory in the source (and
XMLs, etc.) and was not able to find anything.
My tmp folder got cleaned, and I did not changed any config file.
I have opened HBase-8242 (
https://issues.apache.org/jira/browse/HBASE-8242 ) for that. It seems
to be because of
On Mon, Apr 1, 2013 at 6:05 PM, Jean-Marc Spaggiari wrote:
> Hi Stack,
>
> What are the expectations regarding 0.95? Should we open JIRAs for the
> issues we found like for the other releases?
>
>
That'd be great JM.
> I just tried to start it out of the box and it's failing. It tries to
> wri
On Mon, Apr 1, 2013 at 6:01 PM, Enis Söztutar wrote:
> Great work.
>
> How will we effectively communicate that this release can eat your computer
> (developer release)? Any pointers from the last 0.89 attempt?
>
>
I can add to the head of this document,
http://wiki.apache.org/hadoop/Hbase/HBaseV
On Mon, Apr 1, 2013 at 4:59 PM, Jean-Marc Spaggiari wrote:
> This is huge!
>
> Just looking at the JIRAs is staggering. There is many things I'm
> eager to see on a production release.
>
I think my list included issues as yet not resolved... let me fix.
Good on you JM,
St.Ack
> I just tried to start it out of the box and it's failing. It tries
to write on the /var/folders/ directory, which doesn't exist.
I think a failure to launch should sink the RC. :-) Beyond that I'd suggest
crash bugs or recurring ERRORS or data corruption / loss.
On Monday, April 1, 2013, Jean-M
On Mon, Apr 1, 2013 at 6:01 PM, Enis Söztutar wrote:
> How will we effectively communicate that this release can eat your computer
> (developer release)? Any pointers from the last 0.89 attempt?
>
Since Stack figured out the hadoop1, hadoop2 suffix business, how about
adding "-eats-your-data" to
Hi Stack,
What are the expectations regarding 0.95? Should we open JIRAs for the
issues we found like for the other releases?
I just tried to start it out of the box and it's failing. It tries to
write on the /var/folders/ directory, which doesn't exist.
Since it's a dev release, I can configure
Great work.
How will we effectively communicate that this release can eat your computer
(developer release)? Any pointers from the last 0.89 attempt?
Going to hbase.apache.org -> Downloads -> might directly lead users to
download 0.95, and play with it. Should we add something to the home page?
This is huge!
Just looking at the JIRAs is staggering. There is many things I'm
eager to see on a production release.
Thanks for this develper release!
JM
2013/4/1 Stack :
> Here is our first 0.95.0 release candidate. Should we put this out as
> 0.95.0?
>
> The 0.95.x series of releases are de
Here is our first 0.95.0 release candidate. Should we put this out as
0.95.0?
The 0.95.x series of releases are designated "developer releases", a type
of release we have done in the past -- see the 0.89.x series -- where we
let out 'raw', barely-tested product so developers and those generally
i
37 matches
Mail list logo
