Heng Chen created HBASE-15814:
-
Summary: Miss important information in Document of HBase Security
Key: HBASE-15814
URL: https://issues.apache.org/jira/browse/HBASE-15814
Project: HBase
Issue Type
On Tue, May 10, 2016 at 11:02 PM, Sean Busbey wrote:
> Always running hbase-server is equivalent to always running the build
> at root. It takes hours. We should not do that.
>
> Agree.
> An opt-in mode for Yetus that runs tests in all module that depend on
> a changed module would make sense f
Always running hbase-server is equivalent to always running the build
at root. It takes hours. We should not do that.
An opt-in mode for Yetus that runs tests in all module that depend on
a changed module would make sense for projects that have poor module
independence.
That said, every time this
Contributor / committer should watch out for Jenkins builds after his / her
patch gets integrated.
TestRpcMetrics is in hbase-server module.
I think the QA bot should always run tests in hbase-server module. This can
be done by adding hbase-server to CHANGED_MODULES (if it is not included)
in dev-
[
https://issues.apache.org/jira/browse/HBASE-15742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu resolved HBASE-15742.
Resolution: Fixed
TestRpcMetrics passes with the addendum
> Reduce allocation of objects in metrics
>
Hi all
Recently I did some optimization about metrics in HBASE-15742, the patch
only changed the hbase-hadoop2-compat module, and pre-commit builds only
run the tests in this module. However, some other modules import this
module, and some tests failed but we didn't know before committing. I think
[
https://issues.apache.org/jira/browse/HBASE-15742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Yang reopened HBASE-15742:
---
0.98 has a failing test caused by this issue
> Reduce allocation of objects in metrics
> ---
Duo Zhang created HBASE-15813:
-
Summary: Rename DefaultWALProvider to a more specific name and
clean up unnecessary reference to it
Key: HBASE-15813
URL: https://issues.apache.org/jira/browse/HBASE-15813
See HDFS-223 and HDFS-916. There are plenty of issues related. The most
important thing is that we need a suitable api and there is an asynchronous
file system proposal in HADOOP-12910 which does not fit our requirements so
I need to stop it being committed first...
And a default choice in a later
Sangjin Lee created HBASE-15812:
---
Summary: HttpServer fails to come up against hadoop trunk
Key: HBASE-15812
URL: https://issues.apache.org/jira/browse/HBASE-15812
Project: HBase
Issue Type: Bu
On Tue, May 10, 2016 at 10:39 AM, Gary Helmling wrote:
> >
> > The suggestion is that we make this new client the default now in master
> > branch so we have plenty of time to find any issues with the
> > implementation. We'd also enable it as the default because the
> improvement
> > is dramatic
stack created HBASE-15811:
-
Summary: Batch Get after batch Put does not fetch all Cells
Key: HBASE-15811
URL: https://issues.apache.org/jira/browse/HBASE-15811
Project: HBase
Issue Type: Bug
I'm not sure this should be default for 2.0 but I'd definitely like to see it
an option we're comfortable supporting through the duration we are negotiating
with HDFS. Would be one major reason why trying out a 2.0.0 release would be
compelling.
On May 10, 2016, at 10:51 AM, Gary Helmling wr
>
> Yeah the 'push to upstream' work has been started already. See here
>
> https://issues.apache.org/jira/browse/HADOOP-12910
>
> But it is much harder to push code into HDFS than HBase. It is the core of
> all hadoop systems and I do not have many contacts in the hdfs community...
>
>
Yes, I'm fa
>
> The suggestion is that we make this new client the default now in master
> branch so we have plenty of time to find any issues with the
> implementation. We'd also enable it as the default because the improvement
> is dramatic (performance, less moving parts, comprehensible, etc.) and we
> thin
On Mon, May 9, 2016 at 11:59 PM, Gary Helmling wrote:
...
> To me, it seems much safer to actively try to push this upstream into HDFS
> right now, and still pointing to its optional, non-default use in HBase as
> a compelling story. I don't understand why making it the default in 2.0 is
> nece
Build status: Successful
If successful, the website and docs have been generated. 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,
Neemesh created HBASE-15810:
---
Summary: We are running a map reduce/spark job to bulk load hbase
data in one of the environment . While running the job, it is not able to
connect to hbase zookeeper
Key: HBASE-15810
URL
[
https://issues.apache.org/jira/browse/HBASE-7065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ashish Singhi resolved HBASE-7065.
--
Resolution: Duplicate
Handled as part of HBASE-15641
> alter table with multiple actions should
[
https://issues.apache.org/jira/browse/HBASE-8039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ashish Singhi resolved HBASE-8039.
--
Resolution: Duplicate
Fix Version/s: (was: 2.0.0)
Implemented as part of HBASE-14154
Some methods are moved from classes in hadoop-hdfs to classes in
hadoop-hdfs-client.
ClientProtocol.addBlock method adds an extra parameter.
DFSClient.Conf is moved to a separated file and renamed to DFSClientConf.
Not very hard. I promise that I can give a patch within 3 days after the
release of
Yeah the 'push to upstream' work has been started already. See here
https://issues.apache.org/jira/browse/HADOOP-12910
But it is much harder to push code into HDFS than HBase. It is the core of
all hadoop systems and I do not have many contacts in the hdfs community...
And it is more convincing
22 matches
Mail list logo
