Jenkins build became unstable: Hadoop-Hdfs-0.23-Build #217

See

Hadoop-Hdfs-0.23-Build - Build # 217 - Unstable

See https://builds.apache.org/job/Hadoop-Hdfs-0.23-Build/217/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 14450 lines...] [INFO] Executing tasks main: [mk

Hadoop-Hdfs-trunk - Build # 1004 - Still Failing

See https://builds.apache.org/job/Hadoop-Hdfs-trunk/1004/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 12674 lines...] [WARNING] Failed to retrieve plugin descr

Build failed in Jenkins: Hadoop-Hdfs-trunk #1004

See Changes: [suresh] HDFS-3126. Journal stream from Namenode to BackupNode needs to have timeout. Contributed by Hari Mankude. [eli] HDFS-3148. The client should be able to use multiple local interfaces for data transfer. Contribu

[jira] [Created] (HDFS-3183) Add JournalManager implementation to use local namenode, remote namenode and a configured JournalDaemon for storing editlogs

Add JournalManager implementation to use local namenode, remote namenode and a configured JournalDaemon for storing editlogs Key: HDFS-3183

Re: [RESULT] - [VOTE] Rename hadoop branches post hadoop-1.x

Arun, I am even more confused now than I was before: Here you say: > Essentially 'trunk' is where incompatible changes *may* be committed (in >future). We should allow for that. On another thread, responding to Avner (re: MAPREDUCE-4049?) you say, > We do expect 'new features' to make it to t

[jira] [Created] (HDFS-3184) Add public HDFS client API

Add public HDFS client API -- Key: HDFS-3184 URL: https://issues.apache.org/jira/browse/HDFS-3184 Project: Hadoop HDFS Issue Type: New Feature Components: hdfs client Reporter: Tsz Wo (Nicholas),

[jira] [Created] (HDFS-3185) Setup configuration for Journal Manager and Journal Services

Setup configuration for Journal Manager and Journal Services Key: HDFS-3185 URL: https://issues.apache.org/jira/browse/HDFS-3185 Project: Hadoop HDFS Issue Type: Sub-task

[jira] [Created] (HDFS-3186) Sync lagging journal service from the active journal service

Sync lagging journal service from the active journal service Key: HDFS-3186 URL: https://issues.apache.org/jira/browse/HDFS-3186 Project: Hadoop HDFS Issue Type: Sub-task

[jira] [Created] (HDFS-3187) Upgrade guava to 11.0.2

Upgrade guava to 11.0.2 --- Key: HDFS-3187 URL: https://issues.apache.org/jira/browse/HDFS-3187 Project: Hadoop HDFS Issue Type: Sub-task Components: build Affects Versions: 2.0.0 Reporter: Todd

[jira] [Created] (HDFS-3188) Add infrastructure for waiting for a quorum of ListenableFutures to respond

Add infrastructure for waiting for a quorum of ListenableFutures to respond --- Key: HDFS-3188 URL: https://issues.apache.org/jira/browse/HDFS-3188 Project: Hadoop HDFS

[jira] [Created] (HDFS-3189) Add preliminary QJournalProtocol interface, translators

Add preliminary QJournalProtocol interface, translators --- Key: HDFS-3189 URL: https://issues.apache.org/jira/browse/HDFS-3189 Project: Hadoop HDFS Issue Type: Sub-task Component

Re: [RESULT] - [VOTE] Rename hadoop branches post hadoop-1.x

Hi Milind, On Tue, Apr 3, 2012 at 11:27 AM, wrote: > Here you say: > > > > Essentially 'trunk' is where incompatible changes *may* be committed (in > >future). We should allow for that. > What I believe Arun is alluding to here is that we expect for compatibility to be maintained for the lifeti

[jira] [Created] (HDFS-3190) Simple refactors in existing NN code to assist QuorumJournalManager extension

Simple refactors in existing NN code to assist QuorumJournalManager extension - Key: HDFS-3190 URL: https://issues.apache.org/jira/browse/HDFS-3190 Project: Hadoop HDFS

Re: [RESULT] - [VOTE] Rename hadoop branches post hadoop-1.x

Thanks ATM. I guess the "*may*" emphasis confused me. Just to get some more clarity: What would be guideline for a new feature, such as https://issues.apache.org/jira/browse/MAPREDUCE-4049, which maintains compatibility for 1.x, but is not relevant to trunk, because the codebases have completely

Re: [RESULT] - [VOTE] Rename hadoop branches post hadoop-1.x

On Tue, Apr 3, 2012 at 2:37 PM, wrote: > What would be guideline for a new feature, such as > https://issues.apache.org/jira/browse/MAPREDUCE-4049, which maintains > compatibility for 1.x, but is not relevant to trunk, because the codebases > have completely diverged, so cannot be committed to tr

Re: [RESULT] - [VOTE] Rename hadoop branches post hadoop-1.x

To my knowledge, shuffle is already pluggable in 0.23 onwards, as long as it is used only by mapreduce framework. That's why Avner says : "In parallel, I'll try to *learn what exists* in 0.23". (Emphasize my own.) That's why I was wondering about the insistence of committing to trunk first. - Mi

Re: [RESULT] - [VOTE] Rename hadoop branches post hadoop-1.x

If that's the case then there doesn't seem to be any question here. The feature is in trunk, and an implementation could be done for an older release branch that would be compatible with that branch. Sure, the code to implement the feature is quite different between the two branches, but trunk will

Re: [RESULT] - [VOTE] Rename hadoop branches post hadoop-1.x

Great ! Thanks @atm, - milind On 4/3/12 3:21 PM, "Aaron T. Myers" wrote: >If that's the case then there doesn't seem to be any question here. The >feature is in trunk, and an implementation could be done for an older >release branch that would be compatible with that branch. Sure, the code >to

[jira] [Reopened] (HDFS-1378) Edit log replay should track and report file offsets in case of errors

[ https://issues.apache.org/jira/browse/HDFS-1378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colin Patrick McCabe reopened HDFS-1378: Assignee: Colin Patrick McCabe (was: Aaron T. Myers) I'd like to port this to bra

[jira] [Created] (HDFS-3191) Active NN should exit when it cannot write to quorum number of Journal Daemons

Active NN should exit when it cannot write to quorum number of Journal Daemons -- Key: HDFS-3191 URL: https://issues.apache.org/jira/browse/HDFS-3191 Project: Hadoop HDFS

[jira] [Created] (HDFS-3192) Active NN should exit when it has not received a getServiceStatus() rpc from ZKFC for timeout secs

Active NN should exit when it has not received a getServiceStatus() rpc from ZKFC for timeout secs -- Key: HDFS-3192 URL: https://issues.apache.org/jira/browse/HDFS-31

[jira] [Created] (HDFS-3193) HDFS journal logging improvement

HDFS journal logging improvement Key: HDFS-3193 URL: https://issues.apache.org/jira/browse/HDFS-3193 Project: Hadoop HDFS Issue Type: Improvement Components: name-node Reporter: Suresh S