1. File and Ganglia are the only bundled sinks, though there are
socket/json (for chukwa) and graphite sinks patches in the works.
2. Hadoop metrics (and metrics2) is mostly designed for system/process
metrics, which means you'll need to attach jconsole to your map/reduce task
processes to see
See https://builds.apache.org/job/Hadoop-Common-trunk/931/changes
Changes:
[jeagles] HADOOP-10064. Upgrade to maven antrun plugin version 1.7 (Arpit
Agarwal via jeagles)
[kihwal] HDFS-5341. Reduce fsdataset lock duration during directory scanning.
Contributed by Qus-Jiawei.
[jing9]
Robert Rati created HADOOP-10067:
Summary: Missing POM dependency on jsr305
Key: HADOOP-10067
URL: https://issues.apache.org/jira/browse/HADOOP-10067
Project: Hadoop Common
Issue Type:
Robert Rati created HADOOP-10068:
Summary: Improve log4j regex in testFindContainingJar
Key: HADOOP-10068
URL: https://issues.apache.org/jira/browse/HADOOP-10068
Project: Hadoop Common
Issue
On Thu, Oct 24, 2013 at 6:18 AM, Andrew Wang andrew.w...@cloudera.comwrote:
Right now we're on track to have all of those things done by tomorrow.
Since the remaining issues are either not technical or do not involve major
changes, I was hoping we could +1 this merge vote in the spirit of +1
I've realized that I'm very confused about the purpose and the process of
merge votes. I'd like to use this thread for clarification so that we all
know exactly what our votes on a merge thread mean. It's possible that
we'll even want to reconsider whether or not merge vote threads are useful.
Hi Andrew,
I've come to the conclusion that I'm very confused about merge votes. :-)
It's not just about HDFS-4949. I'm confused about all merge votes.
Rather than muddy the waters here, I've started a separate discussion on
common-dev.
I do agree with the general plan outlined here, and I
Hi Aaron,
Thanks for pointing this out. I hadn't seen it, but I just caught up.
This proposal states that 3 binding +1 votes are required for a branch
merge, which makes sense to me. My confusion arises from the fact that
I've seen the voting happening in 2 different places in 2 different ways
On Thu, Oct 24, 2013 at 2:51 PM, Chris Nauroth cnaur...@hortonworks.com wrote:
When the voting happens on jira with a finalized merge patch, I know
exactly what I'm voting for, because it's the same review-and-commit
process that we follow every day with the extra requirement of 3 +1s. When
On Thu, Oct 24, 2013 at 1:45 PM, Chris Nauroth cnaur...@hortonworks.com wrote:
Hi Andrew,
I've come to the conclusion that I'm very confused about merge votes. :-)
It's not just about HDFS-4949. I'm confused about all merge votes.
Rather than muddy the waters here, I've started a separate
(Resend)
No. In the past, committers would merge a branch once the merge vote had been
passed even there were problems in the branch. Below is my understanding of
merge vote.
Feature branch merge votes is the same as the traditional code review-commit
process except that it requires three
Raymond Liu created HADOOP-10069:
Summary: Not need to start secondary namenode upon NN HA?
Key: HADOOP-10069
URL: https://issues.apache.org/jira/browse/HADOOP-10069
Project: Hadoop Common
[
https://issues.apache.org/jira/browse/HADOOP-10069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Raymond Liu resolved HADOOP-10069.
--
Resolution: Duplicate
Not need to start secondary namenode upon NN HA?
Aaron T. Myers created HADOOP-10070:
---
Summary: RPC client doesn't use per-connection conf to determine
server's expected Kerberos principal name
Key: HADOOP-10070
URL:
14 matches
Mail list logo
