[jira] [Created] (HBASE-17489) ClientScanner may send a next request to a RegionScanner which has been exhausted

[Duo Zhang (JIRA)]

Duo Zhang created HBASE-17489:
-

 Summary: ClientScanner may send a next request to a RegionScanner 
which has been exhausted
 Key: HBASE-17489
 URL: https://issues.apache.org/jira/browse/HBASE-17489
 Project: HBase
  Issue Type: Bug
  Components: Client, scan
Affects Versions: 2.0.0
Reporter: Duo Zhang
Priority: Critical
 Fix For: 2.0.0


Found it when implementing HBASE-17045. Seems the final result of the scan is 
correct but no doubt the logic is broken. We need to fix it to stop things get 
worse in the future.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (HBASE-17488) WALEdit should be lazily instantiated

[ChiaPing Tsai (JIRA)]

ChiaPing Tsai created HBASE-17488:
-

 Summary: WALEdit should be lazily instantiated
 Key: HBASE-17488
 URL: https://issues.apache.org/jira/browse/HBASE-17488
 Project: HBase
  Issue Type: Improvement
Reporter: ChiaPing Tsai
Priority: Trivial


Some trivial improvement.
# create the WALEdit on step 3 instead of step 2
# count the cells from coprocessor
# don’t count the mutations which contain the Durability.SKIP_WAL property



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (HBASE-17487) Potential data loss when pipeline is pushed to snapshot

[Ted Yu (JIRA)]

Ted Yu created HBASE-17487:
--

 Summary: Potential data loss when pipeline is pushed to snapshot
 Key: HBASE-17487
 URL: https://issues.apache.org/jira/browse/HBASE-17487
 Project: HBase
  Issue Type: Bug
Reporter: Ted Yu
Assignee: Ted Yu


In CompactingMemStore#pushPipelineToSnapshot() , there is limit of 3 iterations 
of pipeline.swap() call after which an empty ImmutableSegment is used as 
snapshot.

However, after 3rd iteration, the return value from swap() is not checked.
If the 3rd swap() call is successful, the versioned list would be swapped with 
null in pipeline and snapshot being overwritten with the empty ImmutableSegment.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Moving 2.0 forward

[Andrew Purtell]

I'm interested in both split meta and rsgroups. Good news. I'd like to help 
test. 


> On Jan 18, 2017, at 2:53 PM, Stack  wrote:
> 
>> On Wed, Jan 18, 2017 at 2:26 PM, Francis Liu  wrote:
>> 
>> Hi Stack,
>> I'd like to get split meta (HBASE-112288) in 2.x as well. I can have a 2.x
>> draft up next week. Was working on the 1.x version internally.
>> Also if you'd like I can be the owner for rsgroups as well.
>> Thanks,Francis
>> 
>> 
>> 
>> I added splitting meta as a possible and had you and I as owner on
> rsgroups (I was doing to do a bit of testing and doc for this feature).
> 
> Would love to see splittable meta show up. Needs to be rolling upgradeable
> though. Lets chat up on the issue.
> St.Ack
> 
> 
> 
> 
>> 
>> 
>> 
>>On Wednesday, January 18, 2017 11:29 AM, Stack 
>> wrote:
>> 
>> 
>> Done Thiruvel (And thanks Guanghao for adding hbase-replication).
>> St.Ack
>> 
>> On Tue, Jan 17, 2017 at 6:11 PM, Thiruvel Thirumoolan <
>> thiru...@yahoo-inc.com.invalid> wrote:
>> 
>>> Hi Stack,
>>> I would like to add Favored Nodes to the ancillary section.
>>> HBASE-15531: Favored Nodes EnhancementsStatus: Active development.Owner:
>>> Thiruvel Thanks!-Thiruvel
>>> 
>>>   On Monday, January 16, 2017 2:10 PM, Stack  wrote:
>>> 
>>> 
>>> On Mon, Jan 16, 2017 at 3:01 AM, Guanghao Zhang 
>>> wrote:
>>> 
 For 6. Significant contirbs in master only, there are some issues about
 replication operations routed through master. They are sub-task
 of HBASE-10504. And there are other umbrella issue for replication,
>> like
 HBase-14379 Replication V2 and HBASE-15867 Moving HBase Replication
 tracking from Zookeeper to HBase. So i thought we can add a new section
 named
 hbase-replication to possible 2.0.0s. This will help us to track the
>>> state.
 Thanks.
 
>>> 
>>> Thanks Guanghao Zhang. I agree. I made you an editor. If you want to
>> have a
>>> go at a first cut, be my guest. If nothing done in the next day or so,
>> I'll
>>> add this section Sir.
>>> Thanks,
>>> M
>>> 
>>> 
>>> 
>>> 
>> 
>> 
>> 
>> 

Re: Moving 2.0 forward

[Stack]

On Wed, Jan 18, 2017 at 2:26 PM, Francis Liu  wrote:

> Hi Stack,
> I'd like to get split meta (HBASE-112288) in 2.x as well. I can have a 2.x
> draft up next week. Was working on the 1.x version internally.
> Also if you'd like I can be the owner for rsgroups as well.
> Thanks,Francis
>
>
>
> I added splitting meta as a possible and had you and I as owner on
rsgroups (I was doing to do a bit of testing and doc for this feature).

Would love to see splittable meta show up. Needs to be rolling upgradeable
though. Lets chat up on the issue.
St.Ack




>
>
>
> On Wednesday, January 18, 2017 11:29 AM, Stack 
> wrote:
>
>
>  Done Thiruvel (And thanks Guanghao for adding hbase-replication).
> St.Ack
>
> On Tue, Jan 17, 2017 at 6:11 PM, Thiruvel Thirumoolan <
> thiru...@yahoo-inc.com.invalid> wrote:
>
> > Hi Stack,
> > I would like to add Favored Nodes to the ancillary section.
> > HBASE-15531: Favored Nodes EnhancementsStatus: Active development.Owner:
> > Thiruvel Thanks!-Thiruvel
> >
> >On Monday, January 16, 2017 2:10 PM, Stack  wrote:
> >
> >
> >  On Mon, Jan 16, 2017 at 3:01 AM, Guanghao Zhang 
> > wrote:
> >
> > > For 6. Significant contirbs in master only, there are some issues about
> > > replication operations routed through master. They are sub-task
> > > of HBASE-10504. And there are other umbrella issue for replication,
> like
> > > HBase-14379 Replication V2 and HBASE-15867 Moving HBase Replication
> > > tracking from Zookeeper to HBase. So i thought we can add a new section
> > > named
> > > hbase-replication to possible 2.0.0s. This will help us to track the
> > state.
> > > Thanks.
> > >
> >
> > Thanks Guanghao Zhang. I agree. I made you an editor. If you want to
> have a
> > go at a first cut, be my guest. If nothing done in the next day or so,
> I'll
> > add this section Sir.
> > Thanks,
> > M
> >
> >
> >
> >
>
>
>
>

Re: Merge and HMerge

[Apekshit Sharma]

+1, although kind of late since it's already done.
But great to see this 5+ years old issue finally resolved.

On Mon, Jan 16, 2017 at 9:24 PM, Stack  wrote:

> On Sat, Jan 14, 2017 at 9:50 PM, Lars George 
> wrote:
>
> > I think that makes sense. The tool with its custom code dates back to
> > where we had no built in version. I am all for removing all of the tools
> > and leave the API call only. That is the same for an admin then compared
> to
> > calling flush or split.
> >
> > No?
> >
> >
> Sounds good to me.
> St.Ack
>
>
>
> > Lars
> >
> > Sent from my iPhone
> >
> > On 15 Jan 2017, at 04:25, Stephen Jiang  wrote:
> >
> > >> If you remove the util.Merge tool, how then does an operator ask for a
> > merge
> > > in its absence?
> > >
> > > We have a shell command to merge region.  In the past, it calls the
> same
> > RS
> > > side code.  I don't think there is a need to have util.Merge (even if
> we
> > > really want, we can ask this utility to call HBaseAdmin.mergeRegions,
> > which
> > > is the same path from the merge command through 'hbase shell').
> > >
> > > Thanks
> > > Stephen
> > >
> > >> On Fri, Jan 13, 2017 at 11:29 PM, Stack  wrote:
> > >>
> > >> On Fri, Jan 13, 2017 at 7:16 PM, Stephen Jiang <
> syuanjiang...@gmail.com
> > >
> > >> wrote:
> > >>
> > >>> Revive this thread
> > >>>
> > >>> I am in the process of removing Region Server side merge (and split)
> > >>> transaction code in master branch; as now we have merge (and split)
> > >>> procedure(s) from master doing the same thing.
> > >>>
> > >>>
> > >> Good (Issue?)
> > >>
> > >>
> > >>> The Merge tool depends on RS-side merge code.  I'd like to use this
> > >> chance
> > >>> to remove the util.Merge tool.  This is for 2.0 and up releases only.
> > >>> Deprecation does not work here; as keeping the RS-side merge code
> would
> > >>> have duplicate logic in source code and make the new Assignment
> manager
> > >>> code more complicated.
> > >>>
> > >>>
> > >> Could util.Merge be changed to ask the Master run the merge (via
> AMv2)?
> > >>
> > >> If you remove the util.Merge tool, how then does an operator ask for a
> > >> merge in its absence?
> > >>
> > >> Thanks Stephen
> > >>
> > >> S
> > >>
> > >>
> > >>> Please let me know whether you have objection.
> > >>>
> > >>> Thanks
> > >>> Stephen
> > >>>
> > >>> PS.  I could deprecated HMerge code if anyone is really using it.  It
> > has
> > >>> its own logic and standalone (supposed to dangerously work offline
> and
> > >>> merge more than 2 regions - the util.Merge and shell not support
> these
> > >>> functionality for now).
> > >>>
> > >>> On Wed, Nov 16, 2016 at 11:04 AM, Enis Söztutar 
> > >>> wrote:
> > >>>
> >  @Appy what is not clear from above?
> > 
> >  I think we should get rid of both Merge and HMerge.
> > 
> >  We should not have any tool which will work in offline mode by going
> > >> over
> >  the HDFS data. Seems very brittle to be broken when things get
> > changed.
> >  Only use case I can think of is that somehow you end up with a lot
> of
> >  regions and you cannot bring the cluster back up because of OOMs,
> etc
> > >> and
> >  you have to reduce the number of regions in offline mode. However,
> we
> > >> did
> >  not see this kind of thing in any of our customers for the last
> couple
> > >> of
> >  years so far.
> > 
> >  I think we should seriously look into improving normalizer and
> > enabling
> >  that by default for all the tables. Ideally, normalizer should be
> > >> running
> >  much more frequently, and should be configured with higher-level
> goals
> > >>> and
> >  heuristics. Like on average how many regions per node, etc and
> should
> > >> be
> >  looking at the global state (like the balancer) to decide on split /
> > >>> merge
> >  points.
> > 
> >  Enis
> > 
> >  On Wed, Nov 16, 2016 at 1:17 AM, Apekshit Sharma  >
> >  wrote:
> > 
> > > bq. HMerge can merge multiple regions by going over the list of
> > > regions and checking
> > > their sizes.
> > > bq. But both of these tools (Merge and HMerge) are very dangerous
> > >
> > > I came across HMerge and it looks like dead code. Isn't referenced
> > >> from
> > > anywhere except one test. (This is what lars also pointed out in
> the
> >  first
> > > email too).
> > > It would make perfect sense if it was a tool or was being
> referenced
> > >>> from
> > > somewhere, but with lack of either of that, am a bit confused here.
> > > @Enis, you seem to know everything about them, please educate me.
> > > Thanks
> > > - Appy
> > >
> > >
> > >
> > > On Thu, Sep 29, 2016 at 12:43 AM, Enis Söztutar <
> enis@gmail.com>
> > > wrote:
> > >
> > >> Merge has very limited usability singe it can do a single merge
> 

Re: Moving 2.0 forward

[Francis Liu]

Hi Stack,
I'd like to get split meta (HBASE-112288) in 2.x as well. I can have a 2.x 
draft up next week. Was working on the 1.x version internally.
Also if you'd like I can be the owner for rsgroups as well. 
Thanks,Francis






On Wednesday, January 18, 2017 11:29 AM, Stack  wrote:
 

 Done Thiruvel (And thanks Guanghao for adding hbase-replication).
St.Ack

On Tue, Jan 17, 2017 at 6:11 PM, Thiruvel Thirumoolan <
thiru...@yahoo-inc.com.invalid> wrote:

> Hi Stack,
> I would like to add Favored Nodes to the ancillary section.
> HBASE-15531: Favored Nodes EnhancementsStatus: Active development.Owner:
> Thiruvel Thanks!-Thiruvel
>
>    On Monday, January 16, 2017 2:10 PM, Stack  wrote:
>
>
>  On Mon, Jan 16, 2017 at 3:01 AM, Guanghao Zhang 
> wrote:
>
> > For 6. Significant contirbs in master only, there are some issues about
> > replication operations routed through master. They are sub-task
> > of HBASE-10504. And there are other umbrella issue for replication, like
> > HBase-14379 Replication V2 and HBASE-15867 Moving HBase Replication
> > tracking from Zookeeper to HBase. So i thought we can add a new section
> > named
> > hbase-replication to possible 2.0.0s. This will help us to track the
> state.
> > Thanks.
> >
>
> Thanks Guanghao Zhang. I agree. I made you an editor. If you want to have a
> go at a first cut, be my guest. If nothing done in the next day or so, I'll
> add this section Sir.
> Thanks,
> M
>
>
>
>


   

[jira] [Created] (HBASE-17486) Tighten the contract for batch client methods

[Michael Axiak (JIRA)]

Michael Axiak created HBASE-17486:
-

 Summary: Tighten the contract for batch client methods
 Key: HBASE-17486
 URL: https://issues.apache.org/jira/browse/HBASE-17486
 Project: HBase
  Issue Type: Bug
  Components: API
Reporter: Michael Axiak
Priority: Trivial


Right now, the API documentation for Table#get(List) and Table#batch(List, 
Result[]) both leave open the possibility for the ordering of the result array 
to be independent of the input actions.

In at least the batch method case, ordering of the result array is important in 
order to know which partial requests failed in the event of an exception. Since 
that contact is required in the batch case, I think it should be extended to 
the get(List) case as well to make the API easier.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [DISCUSS] hbase-spark module in branch-1 and branch-2

[Ted Yu]

After HBASE-16179 gets reviewed / committed, I should be able to take on
other high priority Spark connector issues.

Cheers

On Wed, Jan 18, 2017 at 12:30 PM, Sean Busbey  wrote:

> I don't doubt that downstream users could "try out" our integration
> using what currently exists in the branch-2. However, we already had
> community consensus on what is necessary for our downstream folks to
> have a good experience with a ready-for-production feature. I don't
> see why we should subject them to a lower bar in a branch-2 release
> than we would have in a branch-1 release just because we're starting
> up a new major version.
>
> The work in HBASE-16179 is certainly a blocker given the rising
> popularity of Spark 2.0 (thanks Ted for getting that work under way, I
> hope we get sufficient review bandwidth to get it finished), but it's not
> everything; e.g. we don't have regression checks in place for the
> things that show up in our docs.
>
> -
> busbey
>
> On Sat, Jan 14, 2017 at 4:52 PM, Ted Yu  wrote:
> > I agree with Devaraj's assessment w.r.t. hbase-spark module in master
> > (which is becoming branch-2).
> >
> > Cheers
> >
> >
> >
> > On Mon, Nov 21, 2016 at 11:46 AM, Devaraj Das 
> wrote:
> >
> >> Hi Sean, I did a quick check with someone from the Spark team here and
> his
> >> opinion was that the hbase-spark module as it currently stands can be
> used
> >> by downstream users to do basic stuff and to try some simple things out,
> >> etc. The integration is improving.
> >> I think we should get what we have in 2.0 (which is the default action
> >> anyways).
> >> Thanks
> >> Devaraj
> >> 
> >> From: Sean Busbey 
> >> Sent: Wednesday, November 16, 2016 9:49 AM
> >> To: dev
> >> Subject: [DISCUSS] hbase-spark module in branch-1 and branch-2
> >>
> >> Hi folks!
> >>
> >> With 2.0 releases coming up, I'd like to revive our prior discussion
> >> on the readiness of the hbase-spark module for downstream users.
> >>
> >> We've had a ticket for tracking the milestones set up for inclusion in
> >> branch-1 releases for about 1.5 years:
> >>
> >> https://issues.apache.org/jira/browse/HBASE-14160
> >>
> >> We still haven't gotten all of the blocker issues completed, AFAIK.
> >>
> >> Is anyone interested in volunteering to knock the rest of these out?
> >>
> >> If they aren't, shall we plan to leave hbase-spark in master and
> >> revert it from branch-2 once it forks for the HBase 2.0 release line?
> >>
> >> This feature isn't a blocker for 2.0; just as we've been planning to
> >> add the hbase-spark module to some 1.y release we can also include it
> >> in a 2.1+ release.
> >>
> >> This does appear to be a feature our downstream users could benefit
> >> from, so I'd hate to continue the current situation where no official
> >> releases include it. This is especially true now that we're looking at
> >> ways to handle changes between Spark 1.6 and Spark 2.0 in HBASE-16179.
> >>
> >> -
> >> busbey
> >>
> >>
>

[jira] [Reopened] (HBASE-17165) Add retry to LoadIncrementalHFiles tool

[stack (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-17165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

stack reopened HBASE-17165:
---

Reopen to try new patch (thanks Mike)

> Add retry to LoadIncrementalHFiles tool
> ---
>
> Key: HBASE-17165
> URL: https://issues.apache.org/jira/browse/HBASE-17165
> Project: HBase
>  Issue Type: Improvement
>  Components: hbase, HFile, tooling
>Affects Versions: 2.0.0, 1.2.3
>Reporter: Mike Grimes
>Assignee: Mike Grimes
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: HBASE-17165.branch-1.2.001.patch, 
> HBASE-17165.branch-1.2.002.patch, HBASE-17165.branch-1.2.003.patch, 
> HBASE-17165.branch-1.2.004.patch, HBASE-17165.master.001.patch, 
> HBASE-17165.master.002.patch
>
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
> As using the LoadIncrementalHFiles tool with S3 as the filesystem is prone to 
> failing due to FileNotFoundExceptions due to inconsistency, simple, 
> configurable retry logic was added.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [DISCUSS] hbase-spark module in branch-1 and branch-2

[Sean Busbey]

I don't doubt that downstream users could "try out" our integration
using what currently exists in the branch-2. However, we already had
community consensus on what is necessary for our downstream folks to
have a good experience with a ready-for-production feature. I don't
see why we should subject them to a lower bar in a branch-2 release
than we would have in a branch-1 release just because we're starting
up a new major version.

The work in HBASE-16179 is certainly a blocker given the rising
popularity of Spark 2.0 (thanks Ted for getting that work under way, I
hope we get sufficient review bandwidth to get it finished), but it's not
everything; e.g. we don't have regression checks in place for the
things that show up in our docs.

-
busbey

On Sat, Jan 14, 2017 at 4:52 PM, Ted Yu  wrote:
> I agree with Devaraj's assessment w.r.t. hbase-spark module in master
> (which is becoming branch-2).
>
> Cheers
>
>
>
> On Mon, Nov 21, 2016 at 11:46 AM, Devaraj Das  wrote:
>
>> Hi Sean, I did a quick check with someone from the Spark team here and his
>> opinion was that the hbase-spark module as it currently stands can be used
>> by downstream users to do basic stuff and to try some simple things out,
>> etc. The integration is improving.
>> I think we should get what we have in 2.0 (which is the default action
>> anyways).
>> Thanks
>> Devaraj
>> 
>> From: Sean Busbey 
>> Sent: Wednesday, November 16, 2016 9:49 AM
>> To: dev
>> Subject: [DISCUSS] hbase-spark module in branch-1 and branch-2
>>
>> Hi folks!
>>
>> With 2.0 releases coming up, I'd like to revive our prior discussion
>> on the readiness of the hbase-spark module for downstream users.
>>
>> We've had a ticket for tracking the milestones set up for inclusion in
>> branch-1 releases for about 1.5 years:
>>
>> https://issues.apache.org/jira/browse/HBASE-14160
>>
>> We still haven't gotten all of the blocker issues completed, AFAIK.
>>
>> Is anyone interested in volunteering to knock the rest of these out?
>>
>> If they aren't, shall we plan to leave hbase-spark in master and
>> revert it from branch-2 once it forks for the HBase 2.0 release line?
>>
>> This feature isn't a blocker for 2.0; just as we've been planning to
>> add the hbase-spark module to some 1.y release we can also include it
>> in a 2.1+ release.
>>
>> This does appear to be a feature our downstream users could benefit
>> from, so I'd hate to continue the current situation where no official
>> releases include it. This is especially true now that we're looking at
>> ways to handle changes between Spark 1.6 and Spark 2.0 in HBASE-16179.
>>
>> -
>> busbey
>>
>>

Re: Moving 2.0 forward

[Stack]

Done Thiruvel (And thanks Guanghao for adding hbase-replication).
St.Ack

On Tue, Jan 17, 2017 at 6:11 PM, Thiruvel Thirumoolan <
thiru...@yahoo-inc.com.invalid> wrote:

> Hi Stack,
> I would like to add Favored Nodes to the ancillary section.
> HBASE-15531: Favored Nodes EnhancementsStatus: Active development.Owner:
> Thiruvel Thanks!-Thiruvel
>
> On Monday, January 16, 2017 2:10 PM, Stack  wrote:
>
>
>  On Mon, Jan 16, 2017 at 3:01 AM, Guanghao Zhang 
> wrote:
>
> > For 6. Significant contirbs in master only, there are some issues about
> > replication operations routed through master. They are sub-task
> > of HBASE-10504. And there are other umbrella issue for replication, like
> > HBase-14379 Replication V2 and HBASE-15867 Moving HBase Replication
> > tracking from Zookeeper to HBase. So i thought we can add a new section
> > named
> > hbase-replication to possible 2.0.0s. This will help us to track the
> state.
> > Thanks.
> >
>
> Thanks Guanghao Zhang. I agree. I made you an editor. If you want to have a
> go at a first cut, be my guest. If nothing done in the next day or so, I'll
> add this section Sir.
> Thanks,
> M
>
>
>
>

ApacheCon CFP closing soon (11 February)

[Rich Bowen]

Hello, fellow Apache enthusiast. Thanks for your participation, and
interest in, the projects of the Apache Software Foundation.

I wanted to remind you that the Call For Papers (CFP) for ApacheCon
North America, and Apache: Big Data North America, closes in less than a
month. If you've been putting it off because there was lots of time
left, it's time to dig for that inspiration and get those talk proposals in.

It's also time to discuss with your developer and user community whether
there's a track of talks that you might want to propose, so that you
have more complete coverage of your project than a talk or two.

We're looking for talks directly, and indirectly, related to projects at
the Apache Software Foundation. These can be anything from in-depth
technical discussions of the projects you work with, to talks about
community, documentation, legal issues, marketing, and so on. We're also
very interested in talks about projects and services built on top of
Apache projects, and case studies of how you use Apache projects to
solve real-world problems.

We are particularly interested in presentations from Apache projects
either in the Incubator, or recently graduated. ApacheCon is where
people come to find out what technology they'll be using this time next
year.

Important URLs are:

To submit a talk for Apache: Big Data -
http://events.linuxfoundation.org/events/apache-big-data-north-america/program/cfp
To submit a talk for ApacheCon -
http://events.linuxfoundation.org/events/apachecon-north-america/program/cfp

To register for Apache: Big Data -
http://events.linuxfoundation.org/events/apache-big-data-north-america/attend/register-
To register for ApacheCon -
http://events.linuxfoundation.org/events/apachecon-north-america/attend/register-

Early Bird registration rates end March 12th, but if you're a committer
on an Apache project, you get the low committer rate, which is less than
half of the early bird rate!

For further updated about ApacheCon, follow us on Twitter, @ApacheCon,
or drop by our IRC channel, #apachecon on the Freenode IRC network. Or
contact me - rbo...@apache.org - with any questions or concerns.

Thanks!

Rich Bowen, VP Conferences, Apache Software Foundation

-- 
(You've received this email because you're on a dev@ or users@ mailing
list of an Apache Software Foundation project. For subscription and
unsubscription information, consult the headers of this email message,
as this varies from one list to another.)

Successful: HBase Generate Website

[Apache Jenkins Server]

Build status: Successful

If successful, the website and docs have been generated. To update the live 
site, follow the instructions below. If failed, skip to the bottom of this 
email.

Use the following commands to download the patch and apply it to a clean branch 
based on origin/asf-site. If you prefer to keep the hbase-site repo around 
permanently, you can skip the clone step.

  git clone https://git-wip-us.apache.org/repos/asf/hbase-site.git

  cd hbase-site
  wget -O- 
https://builds.apache.org/job/hbase_generate_website/463/artifact/website.patch.zip
 | funzip > 406f66a4e89f0d3a52225bce6a5a33cf54b9d75c.patch
  git fetch
  git checkout -b asf-site-406f66a4e89f0d3a52225bce6a5a33cf54b9d75c 
origin/asf-site
  git am --whitespace=fix 406f66a4e89f0d3a52225bce6a5a33cf54b9d75c.patch

At this point, you can preview the changes by opening index.html or any of the 
other HTML pages in your local 
asf-site-406f66a4e89f0d3a52225bce6a5a33cf54b9d75c branch.

There are lots of spurious changes, such as timestamps and CSS styles in 
tables, so a generic git diff is not very useful. To see a list of files that 
have been added, deleted, renamed, changed type, or are otherwise interesting, 
use the following command:

  git diff --name-status --diff-filter=ADCRTXUB origin/asf-site

To see only files that had 100 or more lines changed:

  git diff --stat origin/asf-site | grep -E '[1-9][0-9]{2,}'

When you are satisfied, publish your changes to origin/asf-site using these 
commands:

  git commit --allow-empty -m "Empty commit" # to work around a current ASF 
INFRA bug
  git push origin asf-site-406f66a4e89f0d3a52225bce6a5a33cf54b9d75c:asf-site
  git checkout asf-site
  git branch -D asf-site-406f66a4e89f0d3a52225bce6a5a33cf54b9d75c

Changes take a couple of minutes to be propagated. You can verify whether they 
have been propagated by looking at the Last Published date at the bottom of 
http://hbase.apache.org/. It should match the date in the index.html on the 
asf-site branch in Git.

As a courtesy- reply-all to this email to let other committers know you pushed 
the site.



If failed, see https://builds.apache.org/job/hbase_generate_website/463/console

[jira] [Resolved] (HBASE-17223) Make COS#newInstance(ByteOutput, int) as public API.

[ramkrishna.s.vasudevan (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-17223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

ramkrishna.s.vasudevan resolved HBASE-17223.

Resolution: Won't Fix

This has been resolved in a different way and we don't need this new API any 
more. 

> Make COS#newInstance(ByteOutput, int) as public API.
> 
>
> Key: HBASE-17223
> URL: https://issues.apache.org/jira/browse/HBASE-17223
> Project: HBase
>  Issue Type: Sub-task
>  Components: Protobufs
>Affects Versions: 2.0.0
>Reporter: ramkrishna.s.vasudevan
>Assignee: ramkrishna.s.vasudevan
> Fix For: 2.0.0
>
>
> This is needed for HBASE-16859 since we need the COS#newInstance(ByteOutput) 
> version to be public to have ByteBuffByteOutput support.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (HBASE-17485) [C++] Zookeeper quorum and znode lookup made configurable

[Sudeep Sunthankar (JIRA)]

Sudeep Sunthankar created HBASE-17485:
-

 Summary: [C++] Zookeeper quorum and znode lookup made configurable
 Key: HBASE-17485
 URL: https://issues.apache.org/jira/browse/HBASE-17485
 Project: HBase
  Issue Type: Sub-task
Reporter: Sudeep Sunthankar


Lookup for Zookeeper Quorum and Zookeeper Znode should be done using 
Configuration instance.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (HBASE-17484) Add non cached version of OffheapKV for write path

[ramkrishna.s.vasudevan (JIRA)]

ramkrishna.s.vasudevan created HBASE-17484:
--

 Summary: Add non cached version of OffheapKV for write path
 Key: HBASE-17484
 URL: https://issues.apache.org/jira/browse/HBASE-17484
 Project: HBase
  Issue Type: Sub-task
Affects Versions: 2.0.0
Reporter: ramkrishna.s.vasudevan
Assignee: ramkrishna.s.vasudevan
 Fix For: 2.0.0


After running lot of different performance tests for various scenarios and with 
multi threads we thought that is  better to have a version of OffheapKV in 
write path that does not cache anything and its fixed_overhead is equal to that 
in KeyValue. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (HBASE-17483) Add equals/hashcode for OffheapKeyValue

[ramkrishna.s.vasudevan (JIRA)]

ramkrishna.s.vasudevan created HBASE-17483:
--

 Summary: Add equals/hashcode for OffheapKeyValue
 Key: HBASE-17483
 URL: https://issues.apache.org/jira/browse/HBASE-17483
 Project: HBase
  Issue Type: Sub-task
Affects Versions: 2.0.0
Reporter: ramkrishna.s.vasudevan
Assignee: ramkrishna.s.vasudevan
 Fix For: 2.0.0


OffheapKV does not have the much needed equals/hashcode as in KeyValue. This 
JIRA is to add that.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (HBASE-17081) Flush the entire CompactingMemStore content to disk

[ramkrishna.s.vasudevan (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-17081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

ramkrishna.s.vasudevan resolved HBASE-17081.

Resolution: Fixed

Pushed again to master. Thanks all for the reviews and [~anastas] for reworking 
and rebasing this patch.

> Flush the entire CompactingMemStore content to disk
> ---
>
> Key: HBASE-17081
> URL: https://issues.apache.org/jira/browse/HBASE-17081
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Anastasia Braginsky
>Assignee: Anastasia Braginsky
> Fix For: 2.0.0
>
> Attachments: HBASE-15787_8.patch, HBASE-17081-V01.patch, 
> HBASE-17081-V02.patch, HBASE-17081-V03.patch, HBASE-17081-V04.patch, 
> HBASE-17081-V05.patch, HBASE-17081-V06.patch, HBASE-17081-V06.patch, 
> HBASE-17081-V07.patch, HBASE-17081-V10.patch, HBASE-17081-V13.patch, 
> HBASE-17081-V14.patch, HBASE-17081-V15.patch, HBASE-17081-V16.patch, 
> HBaseMeetupDecember2016-V02.pptx, Pipelinememstore_fortrunk_3.patch
>
>
> Part of CompactingMemStore's memory is held by an active segment, and another 
> part is divided between immutable segments in the compacting pipeline. Upon 
> flush-to-disk request we want to flush all of it to disk, in contrast to 
> flushing only tail of the compacting pipeline.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)