Sean Busbey (JIRA | 28 Feb 18:12 2015
Picon

[jira] [Created] (HBASE-13129) Add troubleshooting hints around WAL retention from replciation

Sean Busbey created HBASE-13129:
-----------------------------------

             Summary: Add troubleshooting hints around WAL retention from replciation
                 Key: HBASE-13129
                 URL: https://issues.apache.org/jira/browse/HBASE-13129
             Project: HBase
          Issue Type: Improvement
          Components: documentation, Replication
            Reporter: Sean Busbey

There's been some confusion on the mailing list about when WALs get retained  / cleaned up once replication
is on at all in a cluster. (ref [this thread|http://mail-archives.apache.org/mod_mbox/hbase-user/201502.mbox/%3CCAMUu0w9aOVBo7kGULiM9tXrULirqs9fm-3ra3pQccYpW_17uOw-JsoAwUIsXosN+BqQ9rBEUg <at> public.gmane.org%3E])

We should add a NOTE in the replication section that wals are saved across enable/disable so long as there
are peers. There looks like there might also be some confusing language around replication being enabled
in the configs vs the enable/disable suspension mechanism.

We should also add a troubleshooting item specific for "my HDFS space keeps growing and it's all in oldWALs."

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

Stephen Jiang | 28 Feb 01:53 2015
Picon

HBASE SHELL: Logic behind "ZK cluster client port has to be the same as default port in config"

In hbase shell code, the following *HMasterCommandLine#startMaster* code
logic has been in the code forever :-).  I just wonder what is the logic
behind it & why it is the case for the error message ("shell will not be
able to find this ZK quorum").

- start zookeeper cluster and return the active ZK server port

- *the return port has to be the same as the default port in the config;
otherwise, throw exception*

- set the default port in configuration to be the return port (why, looks
redundant to me? - if this is not redundant, then after updating the
config, should SHELL be able to find the ZK quorum? - my testing show not,
but I could not figure out reason behind it.)

Here is the code:

        int zkClientPort = conf.getInt(HConstants.ZOOKEEPER_CLIENT_PORT, 0);

        if (zkClientPort == 0) {

          throw new IOException("No config value for "     +
HConstants.ZOOKEEPER_CLIENT_PORT);

        }

        ...

        int clientPort = zooKeeperCluster.startup(zkDataPath);

(Continue reading)

Victoria (JIRA | 27 Feb 22:22 2015
Picon

[jira] [Created] (HBASE-13128) Make HBCK's lock file retry creation and deletion

Victoria created HBASE-13128:
--------------------------------

             Summary: Make HBCK's lock file retry creation and deletion
                 Key: HBASE-13128
                 URL: https://issues.apache.org/jira/browse/HBASE-13128
             Project: HBase
          Issue Type: Improvement
          Components: hbck
            Reporter: Victoria
            Priority: Minor

When hbck runs it creates a lock file to ensure that no two hbck instances are running. We've been seeing
creating and removing that file fail sometimes.
This improvement should make the creation, closing of the file, and the deletion retry multiple times.
This should allow our alerting which uses this command to be more reliable and have fewer false positives.

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

stack (JIRA | 27 Feb 20:05 2015
Picon

[jira] [Created] (HBASE-13127) Add timeouts on all tests so less zombie sightings

stack created HBASE-13127:
-----------------------------

             Summary: Add timeouts on all tests so less zombie sightings
                 Key: HBASE-13127
                 URL: https://issues.apache.org/jira/browse/HBASE-13127
             Project: HBase
          Issue Type: Improvement
          Components: test
            Reporter: stack
            Assignee: stack

[~Apache9] and [~octo47] have been working hard at trying to get our builds passing again. They are almost
there. TRUNK just failed with a zombie TestMasterObserver. Help the lads out by adding timeouts on all
tests so less zombie incidence... will help identify the frequent failing issues.

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

Sean Busbey | 27 Feb 19:06 2015

Minor release cadence for branch-1

Hey folks!

Apologies if I've overlooked this getting discussed already. Do we have a
goal release cadence for minor versions out of branch-1?

My first gut reaction is that it should essentially match the cadence we've
been aiming at for the 0.98 line. That would mean attempting to match
monthly, I think?

The obvious problem with this is that now that we have patch versions, it
means essentially getting a new branch per month for backports. That's
quickly going to get old, even if we presume most additions will move onto
branch-2 in a year or so.

What do folks think about limiting which minor versions patch-level fixes
go into? We could default to the most recent release + current minor dev
and go back farther when requested by the issue filer?

That means in ~3 months we'd expect branch-1 to be working on 1.4 and most
patch-level fixes to go into branch-1.3 and branch-1. If someone reported a
failure and they were on e.g. 1.1.z, we'd also do the fix in branch-1.1 and
branch-1.2.

Or should we just stick with hitting all of the branches on the presumption
that the cherry picks should be trivial?

--

-- 
Sean
Sean Busbey (JIRA | 27 Feb 18:50 2015
Picon

[jira] [Created] (HBASE-13126) Clean up API for unintended methods within non-private classes.

Sean Busbey created HBASE-13126:
-----------------------------------

             Summary: Clean up API for unintended methods within non-private classes.
                 Key: HBASE-13126
                 URL: https://issues.apache.org/jira/browse/HBASE-13126
             Project: HBase
          Issue Type: Task
          Components: API
    Affects Versions: 2.0.0
            Reporter: Sean Busbey
            Priority: Blocker
             Fix For: 2.0.0

Over in the review for HBASE-12972, [~enis] mentioned that one of the HBTU methods wasn't intended for
public consumption.

Can we build a list of such methods across the API, appropriately annotate them for 2.0, and deprecate them
in earlier versions with a warning that they're going to be restricted?

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

stack (JIRA | 27 Feb 18:30 2015
Picon

[jira] [Created] (HBASE-13125) Purge hbase.bucketcache.sizes from the refguide; no such config (should be hbase.bucketcache.size?)

stack created HBASE-13125:
-----------------------------

             Summary: Purge hbase.bucketcache.sizes from the refguide; no such config (should be hbase.bucketcache.size?)
                 Key: HBASE-13125
                 URL: https://issues.apache.org/jira/browse/HBASE-13125
             Project: HBase
          Issue Type: Bug
          Components: documentation
            Reporter: stack
            Priority: Trivial

Came up on mailing list today... a gentleman saw hbase.bucketcache.sizes and didn't know what it was about.

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

Hari Krishna Dara (JIRA | 27 Feb 08:26 2015
Picon

[jira] [Created] (HBASE-13124) Option to collect latencies for individual requests

Hari Krishna Dara created HBASE-13124:
-----------------------------------------

             Summary: Option to collect latencies for individual requests
                 Key: HBASE-13124
                 URL: https://issues.apache.org/jira/browse/HBASE-13124
             Project: HBase
          Issue Type: Improvement
          Components: Performance, test
    Affects Versions: 0.98.6
            Reporter: Hari Krishna Dara

Currently, the only option in {{PerformanceEvaluation}} is to print latency percentile summary at the
end, and it is also not suitable if we are testing for a long duration (as all the timings are collected in
memory). There should be an option to dump the latencies with a timestamp as CSV to a file so that this allows
a detailed analysis on the generated data, such as:
- Percentile calculation at the desired precision on the latencies 
- Latencies over time
- Histograms

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

Picon

[jira] [Created] (HBASE-13123) Minor bug in ROW bloom filter

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

             Summary: Minor bug in ROW bloom filter
                 Key: HBASE-13123
                 URL: https://issues.apache.org/jira/browse/HBASE-13123
             Project: HBase
          Issue Type: Bug
    Affects Versions: 1.0.0, 2.0.0, 1.1.0
            Reporter: ramkrishna.s.vasudevan
            Assignee: ramkrishna.s.vasudevan
            Priority: Minor

While checking the code for Bloom filter found that while checking if a key passes the ROW bloom check we try
to create a bloom key. The bloom key should be constructed only with the row part of the key. But try to form
the bloom key including the meta data part of the key.

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

Solomon Duskis (JIRA | 27 Feb 05:50 2015
Picon

[jira] [Resolved] (HBASE-13113) BufferedMutatorImpl should return currentWriteBufferSize in getWriteBufferSize()


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

Solomon Duskis resolved HBASE-13113.
------------------------------------
      Resolution: Invalid
    Release Note: I misunderstood the meaning of the method.  It's implemented correctly.

> BufferedMutatorImpl should return currentWriteBufferSize in getWriteBufferSize()
> --------------------------------------------------------------------------------
>
>                 Key: HBASE-13113
>                 URL: https://issues.apache.org/jira/browse/HBASE-13113
>             Project: HBase
>          Issue Type: Bug
>    Affects Versions: 2.0.0, 1.0.1
>            Reporter: Solomon Duskis
>            Assignee: Solomon Duskis
>

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

Shuaifeng Zhou (JIRA | 27 Feb 03:16 2015
Picon

[jira] [Created] (HBASE-13122) return codes of some filters not efficent

Shuaifeng Zhou created HBASE-13122:
--------------------------------------

             Summary: return codes of some filters not efficent
                 Key: HBASE-13122
                 URL: https://issues.apache.org/jira/browse/HBASE-13122
             Project: HBase
          Issue Type: Improvement
          Components: Filters
    Affects Versions: 0.98.10.1, 0.94.24, 1.0.1
            Reporter: Shuaifeng Zhou

ColumnRangeFilter:
 when minColumnInclusive is false, it means all the cells at the current row&column not fit the condition,
so it should skip to next column, return code should be NEXT_COL, not SKIP.
FamilyFilter is the similar sitution.

Currently, SKIP will not causing error, but not efficent.

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


Gmane