stop-hbase.sh never stopped once deployed the 0.91 trunk jar onto my hbase
setup. Figured out that the Meta regions were never closed and hbase would
stop only when logging in debug mode is enabled.
Here is the code snippet from HResionServer.java on HBaseTrunk:
else if (this.stopping && LOG.isDe
Good catch.
Also, I think in isOnlyMetaRegionsRemaining(), onlyMetaRegionsRemaining
should be initialized to true so that the cleanup at line 638 can proceed if
this.onlineRegions is empty.
Mind filing a bug ?
Thanks
On Fri, Jun 24, 2011 at 5:52 AM, Akash Ashok wrote:
> stop-hbase.sh never sto
Sure I shall file a Bug
Also I dnt think this condition checking itself is required in run()
if (!onlyMetaRegionsRemaining) {
onlyMetaRegionsRemaining = isOnlyMetaRegionsRemaining();
}
isOnlyMetaRegionsRemaining() is anyways gonna initialize it right ? without
checking the cond
I think the if condition below can be kept. It is an optimization because
isOnlyMetaRegionsRemaining() would loop through
this.onlineRegions.entrySet()
On Fri, Jun 24, 2011 at 7:08 AM, Akash Ashok wrote:
> Sure I shall file a Bug
>
> Also I dnt think this condition checking itself is required in
Yes I agree that would have been an optimization if that condition would
ever fail. But its a condition that will always pass because its a local
variable that initialized to false and thus if (!onlyMetaRegionsRemaining)
always passes .
Please correct me if I am missing something here.
Thanks
I agree.
On Fri, Jun 24, 2011 at 7:36 AM, Akash Ashok wrote:
> Yes I agree that would have been an optimization if that condition would
> ever fail. But its a condition that will always pass because its a local
> variable that initialized to false and thus if
> (!onlyMetaRegionsRemaining)
> a
Dave:
Nicolas has refactored major compaction code extensively.
Can you kindly verify whether HBASE-2770 is still an issue for TRUNK ?
Thanks
-1 on allowing edits of issue comments.
We had this feature disabled on the HBase project for a while but obviously it
is allowed again.
Issues are external memory of a project. If they are volatile, that memory is
volatile, which I find unacceptable, if the record can be selectively or
conven
I will refrain from doing this again.
On Fri, Jun 24, 2011 at 3:07 PM, Andrew Purtell wrote:
> -1 on allowing edits of issue comments.
>
> We had this feature disabled on the HBase project for a while but obviously
> it is allowed again.
>
> Issues are external memory of a project. If they are v
agreed. It's annoying when I make a typo, but I think better overall to
disable the option.
On Fri, Jun 24, 2011 at 3:07 PM, Andrew Purtell wrote:
> -1 on allowing edits of issue comments.
>
> We had this feature disabled on the HBase project for a while but obviously
> it is allowed again.
>
>
BTW modifying the title/description of JIRA is allowed, right ?
On Fri, Jun 24, 2011 at 3:11 PM, Ted Yu wrote:
> I will refrain from doing this again.
>
>
> On Fri, Jun 24, 2011 at 3:07 PM, Andrew Purtell wrote:
>
>> -1 on allowing edits of issue comments.
>>
>> We had this feature disabled on t
Sure, that doesn't change any of the communication recorded on the issue.
- Andy
From: Ted Yu
>To: dev@hbase.apache.org; apurt...@apache.org
>Sent: Friday, June 24, 2011 5:09 PM
>Subject: Re: modifying title of JIRA
>
>
>BTW modifying the title/description of JIRA is allowed, right ?
>
>
>O
I think it's reasonable to modify the title/description of a JIRA. I did this
to one of my own tickets a few weeks ago where after a few review comments a
more refined topic came into focus. So I changed the title, but since all the
comments were still in the ticket there is history on what ha
13 matches
Mail list logo
