Re: FW: Process RIT for META and ROOT- Do we really need to wait for timeout period?

On Mon, Aug 15, 2011 at 9:49 PM, Ramkrishna S Vasudevan wrote: > What you say is when the master sees it in OPENED state.  But if the META > was in OPENING state in zk and that time the master goes down.  Now when the > master comes up again then the master will try to process the OPENING state. >

Re: Build failed in Jenkins: HBase-TRUNK #2117

I made https://issues.apache.org/jira/browse/INFRA-3851 for the too many open files issue. St.Ack On Mon, Aug 15, 2011 at 10:44 PM, Apache Jenkins Server wrote: > See > > Changes: > > [tedyu] HBASE-4197 Added check of scanner against null >

Build failed in Jenkins: HBase-TRUNK #2117

See Changes: [tedyu] HBASE-4197 Added check of scanner against null [tedyu] HBASE-2399 Forced splits only act on the first family in a table (Ming Ma) -- [...truncated 1519 lines...] Tests run: 2,

RE: FW: Process RIT for META and ROOT- Do we really need to wait for timeout period?

Hi Stack, What you say is when the master sees it in OPENED state. But if the META was in OPENING state in zk and that time the master goes down. Now when the master comes up again then the master will try to process the OPENING state. regionsInTransition.put(encodedRegionName, new Reg

Re: HBase exception after upgrading from hbase-0.90-branch to trunk

Oh, are you running on hbase trunk? If so, did you write all your data with TRUNK or did you start up 0.92 on a data that was written w/ 0.90 (It should work but you may have hit an issue). St.Ack On Thu, Aug 11, 2011 at 12:42 PM, Sebastian Bauer wrote: > i had copy of -ROOT- and .META. and -RO

Re: HBase exception after upgrading from hbase-0.90-branch to trunk

What version of hbase is this Sebastian? What you mean by remove -ROOT- and .META. (that doesn't sound good but you probably mean something else though looking at the exception below, maybe this is what you did). St.Ack On Thu, Aug 11, 2011 at 11:54 AM, Sebastian Bauer wrote: > 2011-08-11 20:53

Jenkins build is back to normal : hbase-0.90 #263

See

Re: FW: Process RIT for META and ROOT- Do we really need to wait for timeout period?

On Thu, Aug 11, 2011 at 11:31 PM, Ramkrishna S Vasudevan wrote: > > Hi All, > > The scenario is while opening META region the master goes down and the state > in zookeeper is RS_OPENING for META.  Now when the master comes up it will > process the RIT.  Here master has to wait till the timeoutmoni

Re: Build failed in Jenkins: HBase-TRUNK #2116

Ok. That makes sense. We do not have root access on the apache build box hudson/jenkins. Here: https://builds.apache.org/job/HBase-TRUNK/ A recent issue that was fixed by apache infrastructure was that machines had reverted configuration for ulimit so it was default 1024. It looks like we've lo

Re: TestRollingRestart fail occasionally

If you update the hadoop that hbase ships with to the tip of the branch-0.20-append, does it fail then? The tip has hdfs-1554, hdfs-1554 whereas what hbase ships with does not. St.Ack On Tue, Aug 9, 2011 at 7:09 PM, Zhoushuaifeng wrote: > Hi, > I run TestRollingRestart(0.90.3), it fails occasio

Re: Build failed in Jenkins: HBase-TRUNK #2116

You are right. I use root do it. -邮件原件- 发件人: saint@gmail.com [mailto:saint@gmail.com] 代表 Stack 发送时间: 2011年8月16日 11:59 收件人: dev@hbase.apache.org 主题: Re: Build failed in Jenkins: HBase-TRUNK #2116 How do you mean Gao? If the config is that the jenkins user has a max of 1024 open f

Re: Build failed in Jenkins: HBase-TRUNK #2116

How do you mean Gao? If the config is that the jenkins user has a max of 1024 open files on the machine, unless we are root, there is no way for us to up the ulimit. Or do I misunderstand? Thanks, St.Ack 2011/8/15 Gaojinchao : > Sorry. I mean we can modify the startup script so that the process

Re: Two requests from a grumpy old man

I'm up for taking on a ~24 hour bound on a JIRA amend commit where any changes to a JIRA outside this time bound would require a new JIRA. I'd be on for doing just because it makes life easier for the downstream bundlers even though as Andrew notes, it makes for more JIRAs (of which we have plenty

re: Build failed in Jenkins: HBase-TRUNK #2116

Sorry. I mean we can modify the startup script so that the process can inherit the property. Rather than by modifying the parameters of the operating system. -邮件原件- 发件人: saint@gmail.com [mailto:saint@gmail.com] 代表 Stack 发送时间: 2011年8月16日 11:35 收件人: dev@hbase.apache.org 主题: Re: Bui

Re: Build failed in Jenkins: HBase-TRUNK #2116

Because I think the ceiling is default 1024 and though it says unlimited, its just 1024 (as it is stock linux IIRC). St.Ack 2011/8/15 Gaojinchao : > Why don't try to use ulimit -SHn in test case. > > -邮件原件- > 发件人: Ted Yu [mailto:yuzhih...@gmail.com] > 发送时间: 2011年8月16日 11:10 > 收件人: dev@hbas

Re: Build failed in Jenkins: HBase-TRUNK #2116

Why don't try to use ulimit -SHn in test case. -邮件原件- 发件人: Ted Yu [mailto:yuzhih...@gmail.com] 发送时间: 2011年8月16日 11:10 收件人: dev@hbase.apache.org 主题: Fwd: Build failed in Jenkins: HBase-TRUNK #2116 From: https://builds.apache.org/view/G-L/view/HBase/job/HBase-TRUNK/lastCompletedBuild/testR

Re: Build failed in Jenkins: HBase-TRUNK #2116

Yeah. I see this in our dump of ulimits: [HBase-TRUNK] $ /bin/bash -xe /tmp/hudson859921705333113.sh + ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending

Fwd: Build failed in Jenkins: HBase-TRUNK #2116

From: https://builds.apache.org/view/G-L/view/HBase/job/HBase-TRUNK/lastCompletedBuild/testReport/org.apache.hadoop.hbase.master/TestDistributedLogSplitting/testOrphanLogCreation/ Caused by: java.io.IOException: Too many open files at sun.nio.ch.IOUtil.initPipe(Native Method) at su

Build failed in Jenkins: HBase-TRUNK #2116

See Changes: [tedyu] HBASE-4197 TestCoprocessorInterface demonstrates CustomScanner usage -- [...truncated 29334 lines...] Running org.apache.hadoop.hbase.filter.TestColumnRangeFilter Tests run: 1, F

Build failed in Jenkins: HBase-TRUNK #2115

See Changes: [tedyu] HBASE-4197 RegionServer expects all scanner to be subclasses of HRegion.RegionScanner (Lars Hofhansl) -- [...truncated 1505 lines...] Running org.apache.hadoop.hb

Build failed in Jenkins: hbase-0.90 #262

See Changes: [tedyu] Move 3 JIRAs from 0.90.4 to 0.90.5 where they actually belong -- [...truncated 1175 lines...] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 25.77 sec Running org.

Re: Two requests from a grumpy old man

> As I understand it, we are under a review-then-commit model for > anything that's not trivial. Yes, but with one +1. Give it a few days, others may return their attention to the project and test something, and we discover the JIRA is not finished.   > We can add a new "link" type for JIRA, eg

Re: Two requests from a grumpy old man

On Mon, Aug 15, 2011 at 12:32 PM, Andrew Purtell wrote: >> A day may be too tight, but maybe we can compromise on a few days, or a week? > > > My concern is about providing the community enough opportunity to test a new > change or do CTR. A week is reasonable. As I understand it, we are under a

Re: Two requests from a grumpy old man

> Actually, I think that anybody who maintains any kind of reference to a JIRA > whether in a distribution or in their own head would like the meaning of a > JIRA to be relatively static. I don't remember proposing to change the meaning of a JIRA with amendments. This is a separate conversation.

Re: Two requests from a grumpy old man

> A day may be too tight, but maybe we can compromise on a few days, or a week? My concern is about providing the community enough opportunity to test a new change or do CTR. A week is reasonable. Best regards,    - Andy Problems worthy of attack prove their worth by hitting back. - Piet Hein

Re: Two requests from a grumpy old man

Actually, I think that anybody who maintains any kind of reference to a JIRA whether in a distribution or in their own head would like the meaning of a JIRA to be relatively static. So even if the community doesn't explicitly know that they care about this, I bet they care about the consequences.

Re: Two requests from a grumpy old man

On Wed, Aug 10, 2011 at 1:40 PM, Andrew Purtell wrote: >> Why remove the day limit Andrew? > > > Both proposals seek middle ground between one JIRA that rolls up all related > changes, or a bunch of JIRAs for different aspects of a single commit. I > think both extremes are best to be avoided. I