[jira] [Updated] (HDFS-10220) Namenode failover due to too long loking in LeaseManager.Monitor
[ https://issues.apache.org/jira/browse/HDFS-10220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Fraison updated HDFS-10220: --- Attachment: HADOOP-10220.003.patch Thanks for the comments[Vinayakumar B]. Here is the new patch taking in account your comments. [Ravi Prakash] there is one mistake in my previous comment we must consider if 1k files checked is sufficiently safe for not iterating on the same leases (not on 1k leases). > Namenode failover due to too long loking in LeaseManager.Monitor > > > Key: HDFS-10220 > URL: https://issues.apache.org/jira/browse/HDFS-10220 > Project: Hadoop HDFS > Issue Type: Bug > Components: namenode >Reporter: Nicolas Fraison >Assignee: Nicolas Fraison >Priority: Minor > Attachments: HADOOP-10220.001.patch, HADOOP-10220.002.patch, > HADOOP-10220.003.patch, threaddump_zkfc.txt > > > I have faced a namenode failover due to unresponsive namenode detected by the > zkfc with lot's of WARN messages (5 millions) like this one: > _org.apache.hadoop.hdfs.StateChange: BLOCK* internalReleaseLease: All > existing blocks are COMPLETE, lease removed, file closed._ > On the threaddump taken by the zkfc there are lots of thread blocked due to a > lock. > Looking at the code, there are a lock taken by the LeaseManager.Monitor when > some lease must be released. Due to the really big number of lease to be > released the namenode has taken too many times to release them blocking all > other tasks and making the zkfc thinking that the namenode was not > available/stuck. > The idea of this patch is to limit the number of leased released each time we > check for lease so the lock won't be taken for a too long time period. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HDFS-10250) Ozone: Add key Persistence
[ https://issues.apache.org/jira/browse/HDFS-10250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anu Engineer updated HDFS-10250: Status: Patch Available (was: Open) > Ozone: Add key Persistence > -- > > Key: HDFS-10250 > URL: https://issues.apache.org/jira/browse/HDFS-10250 > Project: Hadoop HDFS > Issue Type: Sub-task > Components: ozone >Affects Versions: HDFS-7240 >Reporter: Anu Engineer >Assignee: Anu Engineer > Fix For: HDFS-7240 > > Attachments: HDFS-10250-HDFS-7240.001.patch > > > Support writing keys to containers. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HDFS-3743) QJM: improve formatting behavior for JNs
[ https://issues.apache.org/jira/browse/HDFS-3743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Masatake Iwasaki updated HDFS-3743: --- Assignee: (was: Masatake Iwasaki) > QJM: improve formatting behavior for JNs > > > Key: HDFS-3743 > URL: https://issues.apache.org/jira/browse/HDFS-3743 > Project: Hadoop HDFS > Issue Type: Sub-task >Affects Versions: QuorumJournalManager (HDFS-3077) >Reporter: Todd Lipcon > > Currently, the JournalNodes automatically format themselves when a new writer > takes over, if they don't have any data for that namespace. However, this has > a few problems: > 1) if the administrator accidentally points a new NN at the wrong quorum (eg > corresponding to another cluster), it will auto-format a directory on those > nodes. This doesn't cause any data loss, but would be better to bail out with > an error indicating that they need to be formatted. > 2) if a journal node crashes and needs to be reformatted, it should be able > to re-join the cluster and start storing new segments without having to fail > over to a new NN. > 3) if 2/3 JNs get accidentally reformatted (eg the mount point becomes > undone), and the user starts the NN, it should fail to start, because it may > end up missing edits. If it auto-formats in this case, the user might have > silent "rollback" of the most recent edits. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (HDFS-3743) QJM: improve formatting behavior for JNs
[ https://issues.apache.org/jira/browse/HDFS-3743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Masatake Iwasaki reassigned HDFS-3743: -- Assignee: Masatake Iwasaki > QJM: improve formatting behavior for JNs > > > Key: HDFS-3743 > URL: https://issues.apache.org/jira/browse/HDFS-3743 > Project: Hadoop HDFS > Issue Type: Sub-task >Affects Versions: QuorumJournalManager (HDFS-3077) >Reporter: Todd Lipcon >Assignee: Masatake Iwasaki > > Currently, the JournalNodes automatically format themselves when a new writer > takes over, if they don't have any data for that namespace. However, this has > a few problems: > 1) if the administrator accidentally points a new NN at the wrong quorum (eg > corresponding to another cluster), it will auto-format a directory on those > nodes. This doesn't cause any data loss, but would be better to bail out with > an error indicating that they need to be formatted. > 2) if a journal node crashes and needs to be reformatted, it should be able > to re-join the cluster and start storing new segments without having to fail > over to a new NN. > 3) if 2/3 JNs get accidentally reformatted (eg the mount point becomes > undone), and the user starts the NN, it should fail to start, because it may > end up missing edits. If it auto-formats in this case, the user might have > silent "rollback" of the most recent edits. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HDFS-10192) Namenode safemode not coming out during failover
[ https://issues.apache.org/jira/browse/HDFS-10192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15222642#comment-15222642 ] Mingliang Liu commented on HDFS-10192: -- s/avoid not/not/ > Namenode safemode not coming out during failover > > > Key: HDFS-10192 > URL: https://issues.apache.org/jira/browse/HDFS-10192 > Project: Hadoop HDFS > Issue Type: Bug > Components: namenode >Reporter: Brahma Reddy Battula >Assignee: Brahma Reddy Battula > Attachments: HDFS-10192-01.patch > > > Scenario: > === > write some blocks > wait till roll edits happen > Stop SNN > Delete some blocks in ANN, wait till the blocks are deleted in DN also. > restart the SNN and Wait till block reports come from datanode to SNN > Kill ANN then make SNN to Active. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HDFS-10192) Namenode safemode not coming out during failover
[
https://issues.apache.org/jira/browse/HDFS-10192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15222641#comment-15222641
]
Mingliang Liu commented on HDFS-10192:
--
I had a look at [HDFS-7046] and found that there was no easy fix to avoid NPE
because of leaving safe mode early in the middle of edit. For now I'm in favor
of the current fix. We are deliberately avoid not leaving safe mode in the
middle of edit when failing over., and check the safe mode after start active
services.
That's said,
# I had a look at the {{BlockManagerSafeMode#checkSafeMode()}}, if the safe
mode is OFF, it will be a no op. This means we can check the safe mode without
side effects (e.g. OFF -> PENDING_THRESHOLD). This is important if
{{BlockManager#checkSafeMode()}} is public.
# I think we can add another unit test that will assert that, the
{{BlockManagerSafeMode#checkSafeMode()}} will never leave safe mode (even
better, a no-op) in the context of start active services. This may be similar
to the test case in the patch (or we can consolidate them in one single test).
Any comment?
> Namenode safemode not coming out during failover
>
>
> Key: HDFS-10192
> URL: https://issues.apache.org/jira/browse/HDFS-10192
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: namenode
>Reporter: Brahma Reddy Battula
>Assignee: Brahma Reddy Battula
> Attachments: HDFS-10192-01.patch
>
>
> Scenario:
> ===
> write some blocks
> wait till roll edits happen
> Stop SNN
> Delete some blocks in ANN, wait till the blocks are deleted in DN also.
> restart the SNN and Wait till block reports come from datanode to SNN
> Kill ANN then make SNN to Active.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HDFS-7661) [umbrella] support hflush and hsync for erasure coded files
[ https://issues.apache.org/jira/browse/HDFS-7661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15222637#comment-15222637 ] Zhe Zhang commented on HDFS-7661: - Thanks for sharing the thoughts [~demongaorui]. Having 2 versions of partial parity block sounds a little arbitrary (e.g. why not 1 or 3 versions). I think the main benefit of storing data cells on parity DNs is that there's no risk of returning wrong data. Hence no need to undo and manage versioning. I think we can create a mechanism to associate the "data cell files" to the parity block (though file naming etc.). > [umbrella] support hflush and hsync for erasure coded files > --- > > Key: HDFS-7661 > URL: https://issues.apache.org/jira/browse/HDFS-7661 > Project: Hadoop HDFS > Issue Type: New Feature > Components: erasure-coding >Reporter: Tsz Wo Nicholas Sze >Assignee: GAO Rui > Attachments: EC-file-flush-and-sync-steps-plan-2015-12-01.png, > HDFS-7661-unitTest-wip-trunk.patch, HDFS-7661-wip.01.patch, > HDFS-EC-file-flush-sync-design-v20160323.pdf, > HDFS-EC-file-flush-sync-design-version1.1.pdf > > > We also need to support hflush/hsync and visible length. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HDFS-10246) Standby NameNode dfshealth.jsp Response very slow
[ https://issues.apache.org/jira/browse/HDFS-10246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15222629#comment-15222629 ] zhangyubiao commented on HDFS-10246: Or I can reduce dfs.namenode.retrycache.expirytime.millis time value and increase dfs.namenode.retrycache.heap.percent value to ease this problem ? > Standby NameNode dfshealth.jsp Response very slow > - > > Key: HDFS-10246 > URL: https://issues.apache.org/jira/browse/HDFS-10246 > Project: Hadoop HDFS > Issue Type: Bug > Components: namenode >Affects Versions: 2.2.0 > Environment: CentOS6.3 Hadoop-2.2.0 >Reporter: zhangyubiao > Labels: bug > Attachments: stacks.txt > > > HDFS Standby NameNode dfshealth.jsp Response very slow -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HDFS-10178) Permanent write failures can happen if pipeline recoveries occur for the first packet
[ https://issues.apache.org/jira/browse/HDFS-10178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15222628#comment-15222628 ] Arpit Agarwal commented on HDFS-10178: -- +1 from me. Not committing it since Masatake has an open question. > Permanent write failures can happen if pipeline recoveries occur for the > first packet > - > > Key: HDFS-10178 > URL: https://issues.apache.org/jira/browse/HDFS-10178 > Project: Hadoop HDFS > Issue Type: Bug >Reporter: Kihwal Lee >Assignee: Kihwal Lee >Priority: Critical > Attachments: HDFS-10178.patch, HDFS-10178.v2.patch, > HDFS-10178.v3.patch, HDFS-10178.v4.patch > > > We have observed that write fails permanently if the first packet doesn't go > through properly and pipeline recovery happens. If the packet header is sent > out, but the data portion of the packet does not reach one or more datanodes > in time, the pipeline recovery will be done against the 0-byte partial block. > > If additional datanodes are added, the block is transferred to the new nodes. > After the transfer, each node will have a meta file containing the header > and 0-length data block file. The pipeline recovery seems to work correctly > up to this point, but write fails when actual data packet is resent. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HDFS-10250) Ozone: Add key Persistence
[ https://issues.apache.org/jira/browse/HDFS-10250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anu Engineer updated HDFS-10250: Attachment: HDFS-10250-HDFS-7240.001.patch > Ozone: Add key Persistence > -- > > Key: HDFS-10250 > URL: https://issues.apache.org/jira/browse/HDFS-10250 > Project: Hadoop HDFS > Issue Type: Sub-task > Components: ozone >Affects Versions: HDFS-7240 >Reporter: Anu Engineer >Assignee: Anu Engineer > Fix For: HDFS-7240 > > Attachments: HDFS-10250-HDFS-7240.001.patch > > > Support writing keys to containers. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (HDFS-10232) Ozone: Make config key naming consistent
[ https://issues.apache.org/jira/browse/HDFS-10232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anu Engineer reassigned HDFS-10232: --- Assignee: Anu Engineer > Ozone: Make config key naming consistent > > > Key: HDFS-10232 > URL: https://issues.apache.org/jira/browse/HDFS-10232 > Project: Hadoop HDFS > Issue Type: Sub-task >Reporter: Anu Engineer >Assignee: Anu Engineer >Priority: Trivial > > We seem to use StorageHandler, ozone, Objectstore etc as prefix. We should > pick one -- Ideally ozone and use that consistently as the prefix for the > ozone config management. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HDFS-10246) Standby NameNode dfshealth.jsp Response very slow
[ https://issues.apache.org/jira/browse/HDFS-10246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15222592#comment-15222592 ] zhangyubiao commented on HDFS-10246: [~mingma],is it OK for set the disable retry cache for standby ? > Standby NameNode dfshealth.jsp Response very slow > - > > Key: HDFS-10246 > URL: https://issues.apache.org/jira/browse/HDFS-10246 > Project: Hadoop HDFS > Issue Type: Bug > Components: namenode >Affects Versions: 2.2.0 > Environment: CentOS6.3 Hadoop-2.2.0 >Reporter: zhangyubiao > Labels: bug > Attachments: stacks.txt > > > HDFS Standby NameNode dfshealth.jsp Response very slow -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HDFS-10251) Ozone: Shutdown cleanly
Anu Engineer created HDFS-10251: --- Summary: Ozone: Shutdown cleanly Key: HDFS-10251 URL: https://issues.apache.org/jira/browse/HDFS-10251 Project: Hadoop HDFS Issue Type: Sub-task Components: ozone Affects Versions: HDFS-7240 Reporter: Anu Engineer Assignee: Anu Engineer Fix For: HDFS-7240 Ozone containers needs to shutdown cleanly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HDFS-10178) Permanent write failures can happen if pipeline recoveries occur for the first packet
[
https://issues.apache.org/jira/browse/HDFS-10178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15222588#comment-15222588
]
Masatake Iwasaki commented on HDFS-10178:
-
{code}
577 // For testing. Delay sending packet downstream
578 if (DataNodeFaultInjector.get().stopSendingPacketDownstream()) {
579 try {
580 Thread.sleep(6);
581 } catch (InterruptedException ie) {
582 throw new IOException("Interrupted while sleeping. Bailing
out.");
583 }
584 }
{code}
Should the test logic be encapsulate in the DataNodeFaultInjector's method? like
{code}
DataNodeFaultInjector dnFaultInjector = new DataNodeFaultInjector() {
int tries = 1;
@Override
public void stopSendingPacketDownstream() throws IOException {
if (tries > 0) {
tries--;
try {
Thread.sleep(6);
} catch (InterruptedException ie) {
throw new IOException("Interrupted while sleeping. Bailing out.");
}
}
}
};
{code}
> Permanent write failures can happen if pipeline recoveries occur for the
> first packet
> -
>
> Key: HDFS-10178
> URL: https://issues.apache.org/jira/browse/HDFS-10178
> Project: Hadoop HDFS
> Issue Type: Bug
>Reporter: Kihwal Lee
>Assignee: Kihwal Lee
>Priority: Critical
> Attachments: HDFS-10178.patch, HDFS-10178.v2.patch,
> HDFS-10178.v3.patch, HDFS-10178.v4.patch
>
>
> We have observed that write fails permanently if the first packet doesn't go
> through properly and pipeline recovery happens. If the packet header is sent
> out, but the data portion of the packet does not reach one or more datanodes
> in time, the pipeline recovery will be done against the 0-byte partial block.
>
> If additional datanodes are added, the block is transferred to the new nodes.
> After the transfer, each node will have a meta file containing the header
> and 0-length data block file. The pipeline recovery seems to work correctly
> up to this point, but write fails when actual data packet is resent.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HDFS-10250) Ozone: Add key Persistence
[ https://issues.apache.org/jira/browse/HDFS-10250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anu Engineer updated HDFS-10250: Summary: Ozone: Add key Persistence (was: Ozone: Add key persistance) > Ozone: Add key Persistence > -- > > Key: HDFS-10250 > URL: https://issues.apache.org/jira/browse/HDFS-10250 > Project: Hadoop HDFS > Issue Type: Sub-task > Components: ozone >Affects Versions: HDFS-7240 >Reporter: Anu Engineer >Assignee: Anu Engineer > Fix For: HDFS-7240 > > > Support writing keys to containers. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HDFS-10250) Ozone: Add key persistance
Anu Engineer created HDFS-10250: --- Summary: Ozone: Add key persistance Key: HDFS-10250 URL: https://issues.apache.org/jira/browse/HDFS-10250 Project: Hadoop HDFS Issue Type: Sub-task Components: ozone Affects Versions: HDFS-7240 Reporter: Anu Engineer Assignee: Anu Engineer Fix For: HDFS-7240 Support writing keys to containers. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HDFS-3743) QJM: improve formatting behavior for JNs
[ https://issues.apache.org/jira/browse/HDFS-3743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15222573#comment-15222573 ] Jian Fang commented on HDFS-3743: - Didn't get a chance to work on this yet and come back again for this issue. Since HADOOP-7001 is a long way to go, I would start to fix a specific case first, i.e., QJM is able to format a new journal node after a journal node is replaced. My thought is to add some logic to the beginning of the following method in QuorumJournalManager Map createNewUniqueEpoch() throws IOException to check all available journal nodes by calling the following method. QuorumCall call = loggers.isFormatted(); The call will wait for all journal nodes to response back and timeout after a given time to avoid waiting forever. If the call times out, simply ignore this call and continue the workflow in createNewUniqueEpoch(). However, if the call is successful, will check if any journal node is not formatted. If not formatted, call format(nsInfo) on this logger to format it. The nsInfo is available to QJM and I think it should be able to format the new journal node successfully. But I have couple questions to ask 1) will this extra step with wait time cause any trouble for this new active QJM? 2) would this extra step introduce a lot of overhead in normal condition without a need to format a journal node? 3) since in our cases, we need to restart the name nodes after a new journal node is in place, the createNewUniqueEpoch() should be called once to format the new journal node. Is this assumption valid? 4) Once a new journal node is formatted, are there any extra steps to make it sync data from other peers? Or this has already been handled by the quorum protocol? Thanks. > QJM: improve formatting behavior for JNs > > > Key: HDFS-3743 > URL: https://issues.apache.org/jira/browse/HDFS-3743 > Project: Hadoop HDFS > Issue Type: Sub-task >Affects Versions: QuorumJournalManager (HDFS-3077) >Reporter: Todd Lipcon > > Currently, the JournalNodes automatically format themselves when a new writer > takes over, if they don't have any data for that namespace. However, this has > a few problems: > 1) if the administrator accidentally points a new NN at the wrong quorum (eg > corresponding to another cluster), it will auto-format a directory on those > nodes. This doesn't cause any data loss, but would be better to bail out with > an error indicating that they need to be formatted. > 2) if a journal node crashes and needs to be reformatted, it should be able > to re-join the cluster and start storing new segments without having to fail > over to a new NN. > 3) if 2/3 JNs get accidentally reformatted (eg the mount point becomes > undone), and the user starts the NN, it should fail to start, because it may > end up missing edits. If it auto-formats in this case, the user might have > silent "rollback" of the most recent edits. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HDFS-10192) Namenode safemode not coming out during failover
[
https://issues.apache.org/jira/browse/HDFS-10192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15222540#comment-15222540
]
Mingliang Liu commented on HDFS-10192:
--
I can verify that the test fails with trunk code. Thanks for the report.
However, I don't think {{startActiveServices()}} should check safe mode
explicitly in the finally block. 1) The block manager safe mode is a state
machine and once the NN leaves it, it should never enter again (unless
requested by user). 2) The block manager safe mode should maintain the state
machine automatically when loading edit logs. That's why we made the
{{BlockManager.checkSafeMode()}} package local, instead of public. If there is
any bug, we should fix it there.
So my gut feeling is that in {{BlockManagerSafeMode#checkSafeMode()}}, we
wrongly bypass the internal state change if
{{namesystem.inTransitionToActive()}} is true. Obviously this is related to
[HDFS-7046]. I'll debug the code for a fix.
Thanks.
> Namenode safemode not coming out during failover
>
>
> Key: HDFS-10192
> URL: https://issues.apache.org/jira/browse/HDFS-10192
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: namenode
>Reporter: Brahma Reddy Battula
>Assignee: Brahma Reddy Battula
> Attachments: HDFS-10192-01.patch
>
>
> Scenario:
> ===
> write some blocks
> wait till roll edits happen
> Stop SNN
> Delete some blocks in ANN, wait till the blocks are deleted in DN also.
> restart the SNN and Wait till block reports come from datanode to SNN
> Kill ANN then make SNN to Active.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HDFS-9943) Support reconfiguring namenode replication confs
[
https://issues.apache.org/jira/browse/HDFS-9943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15222532#comment-15222532
]
Hadoop QA commented on HDFS-9943:
-
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 11s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s {color} | {color:green} The patch appears to include 2 new or modified test
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 6m
34s {color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 40s
{color} | {color:green} trunk passed with JDK v1.8.0_77 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 41s
{color} | {color:green} trunk passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
23s {color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 52s
{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
13s {color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
56s {color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 5s
{color} | {color:green} trunk passed with JDK v1.8.0_77 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 47s
{color} | {color:green} trunk passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
45s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 36s
{color} | {color:green} the patch passed with JDK v1.8.0_77 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 36s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 39s
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 39s
{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 0m 22s
{color} | {color:red} hadoop-hdfs-project/hadoop-hdfs: patch generated 6 new +
290 unchanged - 4 fixed = 296 total (was 294) {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 48s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
12s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m 8s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 4s
{color} | {color:green} the patch passed with JDK v1.8.0_77 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 43s
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 56m 58s {color}
| {color:red} hadoop-hdfs in the patch failed with JDK v1.8.0_77. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 53m 5s {color}
| {color:red} hadoop-hdfs in the patch failed with JDK v1.7.0_95. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
20s {color} | {color:green} Patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 135m 6s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| JDK v1.8.0_77 Failed junit tests | hadoop.hdfs.web.TestWebHDFS |
| | hadoop.hdfs.server.datanode.TestDataNodeMetrics |
| | hadoop.TestRefreshCallQueue |
| JDK v1.7.0_95 Failed junit tests | hadoop.TestRefreshCallQueue |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Image:yetus/hadoop:fbe3e86 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12796603/HDFS-9943-HDFS-9000.001.patch
|
| JIRA Issue | HDFS-9943 |
| Optional Tests | asflicense compile javac javadoc mvninstall mvnsite
unit findbugs checkstyle |
| uname | Linux 086f63801fea 3.13.0-
[jira] [Commented] (HDFS-10178) Permanent write failures can happen if pipeline recoveries occur for the first packet
[
https://issues.apache.org/jira/browse/HDFS-10178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15222523#comment-15222523
]
Hadoop QA commented on HDFS-10178:
--
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 12s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s {color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 6m
36s {color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 41s
{color} | {color:green} trunk passed with JDK v1.8.0_74 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 41s
{color} | {color:green} trunk passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
21s {color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 51s
{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
14s {color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
56s {color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 5s
{color} | {color:green} trunk passed with JDK v1.8.0_74 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 44s
{color} | {color:green} trunk passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
46s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 38s
{color} | {color:green} the patch passed with JDK v1.8.0_74 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 38s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 38s
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 38s
{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 0m 19s
{color} | {color:red} hadoop-hdfs-project/hadoop-hdfs: patch generated 2 new +
99 unchanged - 2 fixed = 101 total (was 101) {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 50s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
11s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
1s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m 9s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 4s
{color} | {color:green} the patch passed with JDK v1.8.0_74 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 39s
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 57m 11s {color}
| {color:red} hadoop-hdfs in the patch failed with JDK v1.8.0_74. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 53m 41s {color}
| {color:red} hadoop-hdfs in the patch failed with JDK v1.7.0_95. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
21s {color} | {color:green} Patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 135m 48s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| JDK v1.8.0_74 Failed junit tests | hadoop.TestRefreshCallQueue |
| | hadoop.hdfs.server.datanode.TestDataNodeMetrics |
| JDK v1.7.0_95 Failed junit tests | hadoop.TestRefreshCallQueue |
| | hadoop.hdfs.shortcircuit.TestShortCircuitCache |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Image:yetus/hadoop:fbe3e86 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12796602/HDFS-10178.v4.patch |
| JIRA Issue | HDFS-10178 |
| Optional Tests | asflicense compile javac javadoc mvninstall mvnsite
unit findbugs checkstyle |
| uname | Linux 3c724ec
[jira] [Commented] (HDFS-8356) Document missing properties in hdfs-default.xml
[
https://issues.apache.org/jira/browse/HDFS-8356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15222508#comment-15222508
]
Hadoop QA commented on HDFS-8356:
-
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 18s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s {color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 25s
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 9m
53s {color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 11m
48s {color} | {color:green} trunk passed with JDK v1.8.0_74 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 10m
13s {color} | {color:green} trunk passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
25s {color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 2m 31s
{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
39s {color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m
32s {color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 3m 1s
{color} | {color:green} trunk passed with JDK v1.8.0_74 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 4m 22s
{color} | {color:green} trunk passed with JDK v1.7.0_95 {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 21s
{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 2m
5s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 11m
47s {color} | {color:green} the patch passed with JDK v1.8.0_74 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 11m 47s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 10m
22s {color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 10m 22s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
27s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 2m 33s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
41s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} xml {color} | {color:green} 0m 1s
{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 5m
15s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 3m 1s
{color} | {color:green} the patch passed with JDK v1.8.0_74 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 4m 12s
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 10m 40s {color}
| {color:red} hadoop-common in the patch failed with JDK v1.8.0_74. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 76m 13s {color}
| {color:red} hadoop-hdfs in the patch failed with JDK v1.8.0_74. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 11m 16s
{color} | {color:green} hadoop-common in the patch passed with JDK v1.7.0_95.
{color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 91m 56s {color}
| {color:red} hadoop-hdfs in the patch failed with JDK v1.7.0_95. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
40s {color} | {color:green} Patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {co
[jira] [Commented] (HDFS-10239) Fsshell mv fails if port usage doesn't match in src and destination paths
[
https://issues.apache.org/jira/browse/HDFS-10239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15222491#comment-15222491
]
Hadoop QA commented on HDFS-10239:
--
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 18s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s {color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 15s
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 7m
46s {color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 9m 7s
{color} | {color:green} trunk passed with JDK v1.8.0_74 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 8m 12s
{color} | {color:green} trunk passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
9s {color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 2m 1s
{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
28s {color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
55s {color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m 27s
{color} | {color:green} trunk passed with JDK v1.8.0_74 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 3m 10s
{color} | {color:green} trunk passed with JDK v1.7.0_95 {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 17s
{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
42s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 9m 9s
{color} | {color:green} the patch passed with JDK v1.8.0_74 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 9m 9s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 8m 12s
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 8m 12s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
10s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 2m 1s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
29s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m
36s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m 27s
{color} | {color:green} the patch passed with JDK v1.8.0_74 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 3m 11s
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 20m 58s {color}
| {color:red} hadoop-common in the patch failed with JDK v1.8.0_74. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 94m 7s {color}
| {color:red} hadoop-hdfs in the patch failed with JDK v1.8.0_74. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 10m 39s
{color} | {color:green} hadoop-common in the patch passed with JDK v1.7.0_95.
{color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 110m 34s
{color} | {color:red} hadoop-hdfs in the patch failed with JDK v1.7.0_95.
{color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
48s {color} | {color:green} Patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 310m 37s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| JDK v1.8.0_74 Failed junit tests |
hadoop.h
[jira] [Commented] (HDFS-9805) TCP_NODELAY not set before SASL handshake in data transfer pipeline
[
https://issues.apache.org/jira/browse/HDFS-9805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15222483#comment-15222483
]
Colin Patrick McCabe commented on HDFS-9805:
Hi [~ghelmling],
Thanks for looking at this. However, it seems like we should be checking to
see if {{ipc.server.tcpnodelay}} is true rather than unconditionally setting
{{TCP_NODELAY}}.
> TCP_NODELAY not set before SASL handshake in data transfer pipeline
> ---
>
> Key: HDFS-9805
> URL: https://issues.apache.org/jira/browse/HDFS-9805
> Project: Hadoop HDFS
> Issue Type: Improvement
> Components: datanode
>Reporter: Gary Helmling
>Assignee: Gary Helmling
> Attachments: HDFS-9805.002.patch, HDFS-9805.003.patch
>
>
> There are a few places in the DN -> DN block transfer pipeline where
> TCP_NODELAY is not set before doing a SASL handshake:
> * in {{DataNode.DataTransfer::run()}}
> * in {{DataXceiver::replaceBlock()}}
> * in {{DataXceiver::writeBlock()}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HDFS-9943) Support reconfiguring namenode replication confs
[ https://issues.apache.org/jira/browse/HDFS-9943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaobing Zhou updated HDFS-9943: Attachment: HDFS-9943-HDFS-9000.001.patch v002 added a bunch of tests. > Support reconfiguring namenode replication confs > > > Key: HDFS-9943 > URL: https://issues.apache.org/jira/browse/HDFS-9943 > Project: Hadoop HDFS > Issue Type: Sub-task > Components: namenode >Reporter: Tsz Wo Nicholas Sze >Assignee: Xiaobing Zhou > Attachments: HDFS-9943-HDFS-9000.000.patch, > HDFS-9943-HDFS-9000.001.patch > > > The following confs should be re-configurable in runtime. > - dfs.namenode.replication.work.multiplier.per.iteration > - dfs.namenode.replication.interval > - dfs.namenode.replication.max-streams > - dfs.namenode.replication.max-streams-hard-limit -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HDFS-10231) libhdfs++: Fix race conditions in RPC layer
[ https://issues.apache.org/jira/browse/HDFS-10231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15222340#comment-15222340 ] James Clampffer commented on HDFS-10231: New patch looks good to me, +1 > libhdfs++: Fix race conditions in RPC layer > --- > > Key: HDFS-10231 > URL: https://issues.apache.org/jira/browse/HDFS-10231 > Project: Hadoop HDFS > Issue Type: Sub-task > Components: hdfs-client >Reporter: James Clampffer >Assignee: Bob Hansen > Attachments: HDFS-10231.HDFS-8707.000.patch, > HDFS-10231.HDFS-8707.001.patch, HDFS-10231.HDFS-8707.002.patch, > HDFS-10231.HDFS-8707.003.patch > > > Namenode calls seem to hang and the retry logic never properly kicks in. It > looks like there's a race condition that leads to a failed rpc call never > properly passing the request object to the new RpcConnectionImpl so things > hang forever. RpcConnectionImpl objects are also kept alive longer than they > should because of a shared_ptr cycle between them and the timeout tracking > objects. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HDFS-10178) Permanent write failures can happen if pipeline recoveries occur for the first packet
[ https://issues.apache.org/jira/browse/HDFS-10178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kihwal Lee updated HDFS-10178: -- Attachment: HDFS-10178.v4.patch > Permanent write failures can happen if pipeline recoveries occur for the > first packet > - > > Key: HDFS-10178 > URL: https://issues.apache.org/jira/browse/HDFS-10178 > Project: Hadoop HDFS > Issue Type: Bug >Reporter: Kihwal Lee >Assignee: Kihwal Lee >Priority: Critical > Attachments: HDFS-10178.patch, HDFS-10178.v2.patch, > HDFS-10178.v3.patch, HDFS-10178.v4.patch > > > We have observed that write fails permanently if the first packet doesn't go > through properly and pipeline recovery happens. If the packet header is sent > out, but the data portion of the packet does not reach one or more datanodes > in time, the pipeline recovery will be done against the 0-byte partial block. > > If additional datanodes are added, the block is transferred to the new nodes. > After the transfer, each node will have a meta file containing the header > and 0-length data block file. The pipeline recovery seems to work correctly > up to this point, but write fails when actual data packet is resent. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HDFS-9917) IBR accumulate more objects when SNN was down for sometime.
[
https://issues.apache.org/jira/browse/HDFS-9917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15222335#comment-15222335
]
Hadoop QA commented on HDFS-9917:
-
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 10s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s {color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 6m
26s {color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 37s
{color} | {color:green} trunk passed with JDK v1.8.0_74 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 40s
{color} | {color:green} trunk passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
21s {color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 50s
{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
14s {color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
53s {color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 2s
{color} | {color:green} trunk passed with JDK v1.8.0_74 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 44s
{color} | {color:green} trunk passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
45s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 35s
{color} | {color:green} the patch passed with JDK v1.8.0_74 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 35s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 38s
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 38s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
18s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 48s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
12s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m 6s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 3s
{color} | {color:green} the patch passed with JDK v1.8.0_74 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 42s
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 54m 25s {color}
| {color:red} hadoop-hdfs in the patch failed with JDK v1.8.0_74. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 53m 5s {color}
| {color:red} hadoop-hdfs in the patch failed with JDK v1.7.0_95. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
20s {color} | {color:green} Patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 131m 53s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| JDK v1.8.0_74 Failed junit tests | hadoop.TestRefreshCallQueue |
| JDK v1.7.0_95 Failed junit tests | hadoop.TestRefreshCallQueue |
| | hadoop.hdfs.TestHFlush |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Image:yetus/hadoop:fbe3e86 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12796572/HDFS-9917-02.patch |
| JIRA Issue | HDFS-9917 |
| Optional Tests | asflicense compile javac javadoc mvninstall mvnsite
unit findbugs checkstyle |
| uname | Linux 1f7798d9e41b 3.13.0-36-lowlatency #63-Ubuntu SMP PREEMPT Wed
Sep 3 21:56:12 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality | /testptch/had
[jira] [Updated] (HDFS-6520) hdfs fsck -move not working
[
https://issues.apache.org/jira/browse/HDFS-6520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Zhuge updated HDFS-6520:
-
Attachment: HDFS-6520-partial.001.patch
Add a partial patch with a unit test that reproduces the problem. Here is the
test output:
{code}
2016-04-01 13:07:00,319 INFO namenode.NameNode (NamenodeFsck.java:(203))
- pmap: ugi = jzhuge
2016-04-01 13:07:00,320 INFO namenode.NameNode (NamenodeFsck.java:(203))
- pmap: path = /
2016-04-01 13:07:00,320 INFO namenode.NameNode (NamenodeFsck.java:(203))
- pmap: move = 1
2016-04-01 13:07:00,320 INFO namenode.NameNode (NamenodeFsck.java:fsck(322)) -
FSCK started by jzhuge (auth:SIMPLE) from /127.0.0.1 for path / at Fri Apr 01
13:07:00 PDT 2016
2016-04-01 13:07:00,320 INFO FSNamesystem.audit
(FSNamesystem.java:logAuditMessage(9575)) - allowed=true ugi=jzhuge
(auth:SIMPLE)ip=/127.0.0.1 cmd=fscksrc=/ dst=null
perm=null proto=rpc
Connecting to namenode via http://localhost:50349
2016-04-01 13:07:00,324 DEBUG security.UserGroupInformation
(UserGroupInformation.java:logPrivilegedAction(1715)) - PrivilegedAction
as:jzhuge (auth:SIMPLE)
from:org.apache.hadoop.ipc.Server$Handler.run(Server.java:2080)
2016-04-01 13:07:00,324 INFO FSNamesystem.audit
(FSNamesystem.java:logAuditMessage(9575)) - allowed=true ugi=jzhuge
(auth:SIMPLE)ip=/127.0.0.1 cmd=getfileinfo src=/lost+found dst=null
perm=null proto=rpc
2016-04-01 13:07:00,325 DEBUG security.UserGroupInformation
(UserGroupInformation.java:logPrivilegedAction(1715)) - PrivilegedAction
as:jzhuge (auth:SIMPLE)
from:org.apache.hadoop.ipc.Server$Handler.run(Server.java:2080)
2016-04-01 13:07:00,326 INFO FSNamesystem.audit
(FSNamesystem.java:logAuditMessage(9575)) - allowed=true ugi=jzhuge
(auth:SIMPLE)ip=/127.0.0.1 cmd=mkdirs src=/lost+found dst=null
perm=jzhuge:supergroup:rwxr-xr-xproto=rpc
2016-04-01 13:07:00,328 DEBUG security.UserGroupInformation
(UserGroupInformation.java:logPrivilegedAction(1715)) - PrivilegedAction
as:jzhuge (auth:SIMPLE)
from:org.apache.hadoop.ipc.Server$Handler.run(Server.java:2080)
2016-04-01 13:07:00,329 INFO FSNamesystem.audit
(FSNamesystem.java:logAuditMessage(9575)) - allowed=true ugi=jzhuge
(auth:SIMPLE)ip=/127.0.0.1 cmd=create
src=/lost+found/srcdat/four/two/4870332656992363927/0 dst=null
perm=jzhuge:supergroup:rw-r--r--proto=rpc
2016-04-01 13:07:00,334 ERROR namenode.NameNode
(NamenodeFsck.java:copyBlock(775)) - Error reading block
org.apache.hadoop.fs.ChecksumException: Checksum error:
/127.0.0.1:50355:BP-152418585-172.16.2.34-1459541215431:1073741827 at 0 exp:
341714375 got: 2114326294
at
org.apache.hadoop.util.DataChecksum.verifyChunkedSums(DataChecksum.java:325)
at
org.apache.hadoop.hdfs.RemoteBlockReader2.readNextPacket(RemoteBlockReader2.java:237)
at
org.apache.hadoop.hdfs.RemoteBlockReader2.read(RemoteBlockReader2.java:156)
at
org.apache.hadoop.hdfs.server.namenode.NamenodeFsck.copyBlock(NamenodeFsck.java:766)
at
org.apache.hadoop.hdfs.server.namenode.NamenodeFsck.copyBlocksToLostFound(NamenodeFsck.java:657)
at
org.apache.hadoop.hdfs.server.namenode.NamenodeFsck.check(NamenodeFsck.java:574)
at
org.apache.hadoop.hdfs.server.namenode.NamenodeFsck.check(NamenodeFsck.java:438)
at
org.apache.hadoop.hdfs.server.namenode.NamenodeFsck.check(NamenodeFsck.java:438)
at
org.apache.hadoop.hdfs.server.namenode.NamenodeFsck.check(NamenodeFsck.java:438)
at
org.apache.hadoop.hdfs.server.namenode.NamenodeFsck.check(NamenodeFsck.java:438)
at
org.apache.hadoop.hdfs.server.namenode.NamenodeFsck.fsck(NamenodeFsck.java:346)
at
org.apache.hadoop.hdfs.server.namenode.FsckServlet$1.run(FsckServlet.java:67)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:415)
at
org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1693)
at
org.apache.hadoop.hdfs.server.namenode.FsckServlet.doGet(FsckServlet.java:58)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1221)
at
org.apache.hadoop.http.HttpServer2$QuotingInputFilter.doFilter(HttpServer2.java:1298)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1212)
at org.apache.hadoop.http.NoCacheFilter.doFilter(NoCacheFilter.java:45)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1212)
at org.apache.hadoop.http.NoCach
[jira] [Commented] (HDFS-10246) Standby NameNode dfshealth.jsp Response very slow
[ https://issues.apache.org/jira/browse/HDFS-10246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1537#comment-1537 ] zhangyubiao commented on HDFS-10246: [~mingma],thanks you > Standby NameNode dfshealth.jsp Response very slow > - > > Key: HDFS-10246 > URL: https://issues.apache.org/jira/browse/HDFS-10246 > Project: Hadoop HDFS > Issue Type: Bug > Components: namenode >Affects Versions: 2.2.0 > Environment: CentOS6.3 Hadoop-2.2.0 >Reporter: zhangyubiao > Labels: bug > Attachments: stacks.txt > > > HDFS Standby NameNode dfshealth.jsp Response very slow -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HDFS-10246) Standby NameNode dfshealth.jsp Response very slow
[ https://issues.apache.org/jira/browse/HDFS-10246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] zhangyubiao updated HDFS-10246: --- Summary: Standby NameNode dfshealth.jsp Response very slow (was: HDFS Standby NameNode dfshealth.jsp Response very slow ) > Standby NameNode dfshealth.jsp Response very slow > - > > Key: HDFS-10246 > URL: https://issues.apache.org/jira/browse/HDFS-10246 > Project: Hadoop HDFS > Issue Type: Bug > Components: namenode >Affects Versions: 2.2.0 > Environment: CentOS6.3 Hadoop-2.2.0 >Reporter: zhangyubiao > Labels: bug > Attachments: stacks.txt > > > HDFS Standby NameNode dfshealth.jsp Response very slow -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HDFS-10249) HDFS ActiveNameNode downloadImageToStorage Cause Rpc Respone Slowly
zhangyubiao created HDFS-10249: -- Summary: HDFS ActiveNameNode downloadImageToStorage Cause Rpc Respone Slowly Key: HDFS-10249 URL: https://issues.apache.org/jira/browse/HDFS-10249 Project: Hadoop HDFS Issue Type: Bug Components: namenode Environment: CentOS6.3 Hadoop-2.2.0 Reporter: zhangyubiao HDFS Active NameNode downloadImageToStorage Cause Rpc Respone Slowly Cause DataNode Apparent death, And The Datanode recovery when the fsimage download finish -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HDFS-10249) ActiveNameNode downloadImageToStorage Cause Rpc Respone Slowly
[ https://issues.apache.org/jira/browse/HDFS-10249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] zhangyubiao updated HDFS-10249: --- Summary: ActiveNameNode downloadImageToStorage Cause Rpc Respone Slowly (was: HDFS ActiveNameNode downloadImageToStorage Cause Rpc Respone Slowly) > ActiveNameNode downloadImageToStorage Cause Rpc Respone Slowly > > > Key: HDFS-10249 > URL: https://issues.apache.org/jira/browse/HDFS-10249 > Project: Hadoop HDFS > Issue Type: Bug > Components: namenode > Environment: CentOS6.3 Hadoop-2.2.0 >Reporter: zhangyubiao > > HDFS Active NameNode downloadImageToStorage Cause Rpc Respone Slowly Cause > DataNode Apparent death, And The Datanode recovery when the fsimage download > finish -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HDFS-9917) IBR accumulate more objects when SNN was down for sometime.
[ https://issues.apache.org/jira/browse/HDFS-9917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brahma Reddy Battula updated HDFS-9917: --- Attachment: HDFS-9917-02.patch Re-uploaded the trunk patch to trigger Jenkins.. > IBR accumulate more objects when SNN was down for sometime. > --- > > Key: HDFS-9917 > URL: https://issues.apache.org/jira/browse/HDFS-9917 > Project: Hadoop HDFS > Issue Type: Bug >Affects Versions: 2.7.2 >Reporter: Brahma Reddy Battula >Assignee: Brahma Reddy Battula >Priority: Critical > Attachments: HDFS-9917-02.patch, HDFS-9917-branch-2.7.patch, > HDFS-9917.patch > > > SNN was down for sometime because of some reasons..After restarting SNN,it > became unreponsive because > - 29 DN's sending IBR in each 5 million ( most of them are delete IBRs), > where as each datanode had only ~2.5 million blocks. > - GC can't trigger on this objects since all will be under RPC queue. > To recover this( to clear this objects) ,restarted all the DN's one by > one..This issue happened in 2.4.1 where split of blockreport was not > available. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HDFS-9917) IBR accumulate more objects when SNN was down for sometime.
[ https://issues.apache.org/jira/browse/HDFS-9917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brahma Reddy Battula updated HDFS-9917: --- Attachment: (was: HDFS-9917-02.patch) > IBR accumulate more objects when SNN was down for sometime. > --- > > Key: HDFS-9917 > URL: https://issues.apache.org/jira/browse/HDFS-9917 > Project: Hadoop HDFS > Issue Type: Bug >Affects Versions: 2.7.2 >Reporter: Brahma Reddy Battula >Assignee: Brahma Reddy Battula >Priority: Critical > Attachments: HDFS-9917-branch-2.7.patch, HDFS-9917.patch > > > SNN was down for sometime because of some reasons..After restarting SNN,it > became unreponsive because > - 29 DN's sending IBR in each 5 million ( most of them are delete IBRs), > where as each datanode had only ~2.5 million blocks. > - GC can't trigger on this objects since all will be under RPC queue. > To recover this( to clear this objects) ,restarted all the DN's one by > one..This issue happened in 2.4.1 where split of blockreport was not > available. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HDFS-9917) IBR accumulate more objects when SNN was down for sometime.
[
https://issues.apache.org/jira/browse/HDFS-9917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15222151#comment-15222151
]
Brahma Reddy Battula commented on HDFS-9917:
Raised HDFS-10245 and HDFS-10248 for {{Findbugs warnings}} and {{ASF License
warnings}} and Test failures are unrelated.
> IBR accumulate more objects when SNN was down for sometime.
> ---
>
> Key: HDFS-9917
> URL: https://issues.apache.org/jira/browse/HDFS-9917
> Project: Hadoop HDFS
> Issue Type: Bug
>Affects Versions: 2.7.2
>Reporter: Brahma Reddy Battula
>Assignee: Brahma Reddy Battula
>Priority: Critical
> Attachments: HDFS-9917-02.patch, HDFS-9917-branch-2.7.patch,
> HDFS-9917.patch
>
>
> SNN was down for sometime because of some reasons..After restarting SNN,it
> became unreponsive because
> - 29 DN's sending IBR in each 5 million ( most of them are delete IBRs),
> where as each datanode had only ~2.5 million blocks.
> - GC can't trigger on this objects since all will be under RPC queue.
> To recover this( to clear this objects) ,restarted all the DN's one by
> one..This issue happened in 2.4.1 where split of blockreport was not
> available.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (HDFS-10248) Fix ASF License warnings in branch-2.7
Brahma Reddy Battula created HDFS-10248: --- Summary: Fix ASF License warnings in branch-2.7 Key: HDFS-10248 URL: https://issues.apache.org/jira/browse/HDFS-10248 Project: Hadoop HDFS Issue Type: Bug Reporter: Brahma Reddy Battula Assignee: Brahma Reddy Battula Please have a look following PreCommit build on branch-2.7. https://builds.apache.org/job/PreCommit-HDFS-Build/15036/artifact/patchprocess/patch-asflicense-problems.txt -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HDFS-10217) show "blockScheduled count" in datanodes table.
[ https://issues.apache.org/jira/browse/HDFS-10217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15222117#comment-15222117 ] Brahma Reddy Battula commented on HDFS-10217: - can anybody review this..? > show "blockScheduled count" in datanodes table. > --- > > Key: HDFS-10217 > URL: https://issues.apache.org/jira/browse/HDFS-10217 > Project: Hadoop HDFS > Issue Type: Improvement >Reporter: Brahma Reddy Battula >Assignee: Brahma Reddy Battula > Attachments: HDFS-10217.patch > > > It will more useful for debugging purpose where user can see how many blocks > got schduled for DN -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HDFS-6520) hdfs fsck -move not working
[
https://issues.apache.org/jira/browse/HDFS-6520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15222114#comment-15222114
]
John Zhuge commented on HDFS-6520:
--
In this test case, {{echo CORRUPT >/path/to/block}} is used to corrupt the
block.
> hdfs fsck -move not working
> ---
>
> Key: HDFS-6520
> URL: https://issues.apache.org/jira/browse/HDFS-6520
> Project: Hadoop HDFS
> Issue Type: Bug
>Affects Versions: 2.4.0
>Reporter: Shengjun Xin
>Assignee: John Zhuge
>
> I met some error when I run fsck -move.
> My steps are as the following:
> 1. Set up a pseudo cluster
> 2. Copy a file to hdfs
> 3. Corrupt a block of the file
> 4. Run fsck to check:
> {code}
> Connecting to namenode via http://localhost:50070
> FSCK started by hadoop (auth:SIMPLE) from /127.0.0.1 for path /user/hadoop at
> Wed Jun 11 15:58:38 CST 2014
> .
> /user/hadoop/fsck-test: CORRUPT blockpool
> BP-654596295-10.37.7.84-1402466764642 block blk_1073741825
> /user/hadoop/fsck-test: MISSING 1 blocks of total size 1048576 B.Status:
> CORRUPT
> Total size:4104304 B
> Total dirs:1
> Total files: 1
> Total symlinks:0
> Total blocks (validated): 4 (avg. block size 1026076 B)
>
> CORRUPT FILES:1
> MISSING BLOCKS: 1
> MISSING SIZE: 1048576 B
> CORRUPT BLOCKS: 1
>
> Minimally replicated blocks: 3 (75.0 %)
> Over-replicated blocks:0 (0.0 %)
> Under-replicated blocks: 0 (0.0 %)
> Mis-replicated blocks: 0 (0.0 %)
> Default replication factor:1
> Average block replication: 0.75
> Corrupt blocks:1
> Missing replicas: 0 (0.0 %)
> Number of data-nodes: 1
> Number of racks: 1
> FSCK ended at Wed Jun 11 15:58:38 CST 2014 in 1 milliseconds
> The filesystem under path '/user/hadoop' is CORRUPT
> {code}
> 5. Run fsck -move to move the corrupted file to /lost+found and the error
> message in the namenode log:
> {code}
> 2014-06-11 15:48:16,686 INFO org.apache.hadoop.hdfs.server.namenode.NameNode:
> FSCK started by hadoop (auth:SIMPLE) from /127.0.0.1 for path /user/hadoop at
> Wed Jun 11 15:48:16 CST 2014
> 2014-06-11 15:48:16,894 INFO
> org.apache.hadoop.hdfs.server.namenode.FSEditLog: Number of transactions: 35
> Total time for transactions(ms): 9 Number of transactions batched in Syncs: 0
> Number of syncs: 25 SyncTimes(ms): 73
> 2014-06-11 15:48:16,991 ERROR
> org.apache.hadoop.hdfs.server.namenode.NameNode: Error reading block
> java.io.IOException: Expected empty end-of-read packet! Header: PacketHeader
> with packetLen=66048 header data: offsetInBlock: 65536
> seqno: 1
> lastPacketInBlock: false
> dataLen: 65536
> at
> org.apache.hadoop.hdfs.RemoteBlockReader2.readTrailingEmptyPacket(RemoteBlockReader2.java:259)
> at
> org.apache.hadoop.hdfs.RemoteBlockReader2.readNextPacket(RemoteBlockReader2.java:220)
> at
> org.apache.hadoop.hdfs.RemoteBlockReader2.read(RemoteBlockReader2.java:138)
> at
> org.apache.hadoop.hdfs.server.namenode.NamenodeFsck.copyBlock(NamenodeFsck.java:649)
> at
> org.apache.hadoop.hdfs.server.namenode.NamenodeFsck.copyBlocksToLostFound(NamenodeFsck.java:543)
> at
> org.apache.hadoop.hdfs.server.namenode.NamenodeFsck.check(NamenodeFsck.java:460)
> at
> org.apache.hadoop.hdfs.server.namenode.NamenodeFsck.check(NamenodeFsck.java:324)
> at
> org.apache.hadoop.hdfs.server.namenode.NamenodeFsck.fsck(NamenodeFsck.java:233)
> at
> org.apache.hadoop.hdfs.server.namenode.FsckServlet$1.run(FsckServlet.java:67)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:415)
> at
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1548)
> at
> org.apache.hadoop.hdfs.server.namenode.FsckServlet.doGet(FsckServlet.java:58)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
> at
> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)
> at
> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1221)
> at
> org.apache.hadoop.http.HttpServer2$QuotingInputFilter.doFilter(HttpServer2.java:1192)
> at
> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1212)
> at
> org.apache.hadoop.http.NoCacheFilter.doFilter(NoCacheFilter.java:45)
> at
> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1212)
> at
> org.apache.hadoop.http.NoCacheFilter.doFilter(NoCacheFilter.java:45)
>
[jira] [Updated] (HDFS-8356) Document missing properties in hdfs-default.xml
[ https://issues.apache.org/jira/browse/HDFS-8356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ray Chiang updated HDFS-8356: - Attachment: HDFS-8356.013.patch - Handle feedback on TestHdfsConfigFields.java > Document missing properties in hdfs-default.xml > --- > > Key: HDFS-8356 > URL: https://issues.apache.org/jira/browse/HDFS-8356 > Project: Hadoop HDFS > Issue Type: Bug > Components: documentation >Affects Versions: 2.7.0 >Reporter: Ray Chiang >Assignee: Ray Chiang > Labels: supportability, test > Attachments: HDFS-8356.001.patch, HDFS-8356.002.patch, > HDFS-8356.003.patch, HDFS-8356.004.patch, HDFS-8356.005.patch, > HDFS-8356.006.patch, HDFS-8356.007.patch, HDFS-8356.008.patch, > HDFS-8356.009.patch, HDFS-8356.010.patch, HDFS-8356.011.patch, > HDFS-8356.012.patch, HDFS-8356.013.patch > > > The following properties are currently not defined in hdfs-default.xml. These > properties should either be > A) documented in hdfs-default.xml OR > B) listed as an exception (with comments, e.g. for internal use) in the > TestHdfsConfigFields unit test -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HDFS-10238) Ozone : Add chunk persistance
[ https://issues.apache.org/jira/browse/HDFS-10238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Nauroth updated HDFS-10238: - Resolution: Fixed Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) [~anu], thank you for the patch. I have committed this to the HDFS-7240 feature branch. > Ozone : Add chunk persistance > - > > Key: HDFS-10238 > URL: https://issues.apache.org/jira/browse/HDFS-10238 > Project: Hadoop HDFS > Issue Type: Sub-task > Components: ozone >Affects Versions: HDFS-7240 >Reporter: Anu Engineer >Assignee: Anu Engineer > Fix For: HDFS-7240 > > Attachments: HDFS-10238-HDFS-7240.001.patch, > HDFS-10238-HDFS-7240.002.patch > > > Add support for chunks in containers for ozone. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HDFS-10239) Fsshell mv fails if port usage doesn't match in src and destination paths
[
https://issues.apache.org/jira/browse/HDFS-10239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kuhu Shukla updated HDFS-10239:
---
Attachment: HDFS-10239.002.patch
Updating patch with minor checkstyle fix. Test failures locally pass and seem
unrelated. Investigating further. Requesting [~kihwal] for comments on the
approach in the mean time.Thanks a lot!
> Fsshell mv fails if port usage doesn't match in src and destination paths
> -
>
> Key: HDFS-10239
> URL: https://issues.apache.org/jira/browse/HDFS-10239
> Project: Hadoop HDFS
> Issue Type: Bug
>Affects Versions: 2.7.2
>Reporter: Kuhu Shukla
>Assignee: Kuhu Shukla
> Attachments: HDFS-10239.001.patch, HDFS-10239.002.patch
>
>
> If one of the src or destination fs URIs does not contain the port while the
> other one does, the MoveCommands#processPath preemptively throws
> PathIOException "Does not match target filesystem".
> eg.
> {code}
> -bash-4.1$ hadoop fs -mv hdfs://localhost:8020/tmp/foo3
> hdfs://localhost/tmp/foo4
> mv: `hdfs://localhost:8020:8020/tmp/foo3': Does not match target filesystem
> {code}
> This is due to strict string check in {{processPath}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HDFS-10238) Ozone : Add chunk persistance
[ https://issues.apache.org/jira/browse/HDFS-10238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15222044#comment-15222044 ] Anu Engineer commented on HDFS-10238: - [~cnauroth], yes you are right. Please go ahead. Thanks for fixing it. > Ozone : Add chunk persistance > - > > Key: HDFS-10238 > URL: https://issues.apache.org/jira/browse/HDFS-10238 > Project: Hadoop HDFS > Issue Type: Sub-task > Components: ozone >Affects Versions: HDFS-7240 >Reporter: Anu Engineer >Assignee: Anu Engineer > Fix For: HDFS-7240 > > Attachments: HDFS-10238-HDFS-7240.001.patch, > HDFS-10238-HDFS-7240.002.patch > > > Add support for chunks in containers for ozone. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (HDFS-9450) Fix failing HDFS tests on HDFS-7240 Ozone branch.
[ https://issues.apache.org/jira/browse/HDFS-9450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arpit Agarwal resolved HDFS-9450. - Resolution: Resolved These failing tests succeed after the branch was rebased - closing. > Fix failing HDFS tests on HDFS-7240 Ozone branch. > - > > Key: HDFS-9450 > URL: https://issues.apache.org/jira/browse/HDFS-9450 > Project: Hadoop HDFS > Issue Type: Sub-task > Components: test >Reporter: Chris Nauroth >Assignee: Xiaobing Zhou > > Several test failures have been introduced on the HDFS-7240 Ozone feature > branch. This issue tracks fixing those tests. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HDFS-10238) Ozone : Add chunk persistance
[
https://issues.apache.org/jira/browse/HDFS-10238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15222031#comment-15222031
]
Chris Nauroth commented on HDFS-10238:
--
[~anu], in {{writeChunk}}, I think the handling of {{InterruptedException}}
needs to re-throw an {{IOException}} after re-raising the interrupted flag.
Otherwise, it would look like the operation succeeded. {{readChunk}} already
does this, so there is no change required there.
Let me know if you agree, and I'll make this minor one-line change before
committing. I am +1 for patch v002 otherwise.
> Ozone : Add chunk persistance
> -
>
> Key: HDFS-10238
> URL: https://issues.apache.org/jira/browse/HDFS-10238
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: ozone
>Affects Versions: HDFS-7240
>Reporter: Anu Engineer
>Assignee: Anu Engineer
> Fix For: HDFS-7240
>
> Attachments: HDFS-10238-HDFS-7240.001.patch,
> HDFS-10238-HDFS-7240.002.patch
>
>
> Add support for chunks in containers for ozone.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HDFS-9782) RollingFileSystemSink should have configurable roll interval
[ https://issues.apache.org/jira/browse/HDFS-9782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15221989#comment-15221989 ] Karthik Kambatla commented on HDFS-9782: I see your point, but given the unlikeliness of someone differentiating between 30 seconds and a 1 minute, I ll keep it simple and drop seconds altogether. > RollingFileSystemSink should have configurable roll interval > > > Key: HDFS-9782 > URL: https://issues.apache.org/jira/browse/HDFS-9782 > Project: Hadoop HDFS > Issue Type: Improvement >Reporter: Daniel Templeton >Assignee: Daniel Templeton > Attachments: HDFS-9782.001.patch, HDFS-9782.002.patch, > HDFS-9782.003.patch, HDFS-9782.004.patch, HDFS-9782.005.patch, > HDFS-9782.006.patch > > > Right now it defaults to rolling at the top of every hour. Instead that > interval should be configurable. The interval should also allow for some > play so that all hosts don't try to flush their files simultaneously. > I'm filing this in HDFS because I suspect it will involve touching the HDFS > tests. If it turns out not to, I'll move it into common instead. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HDFS-10246) HDFS Standby NameNode dfshealth.jsp Response very slow
[
https://issues.apache.org/jira/browse/HDFS-10246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15221980#comment-15221980
]
Ming Ma commented on HDFS-10246:
[~piaoyu zhang] based on the thread dump you provided, it is HDFS-7609 which
caused {{addCacheEntry}} to hold the {{FSNamesystem}}'s lock for too long. To
add to [~vinayrpet]'s point, with HDFS-7182 jmx access doesn't need to acquire
{{FSNamesystem}}'s lock.
> HDFS Standby NameNode dfshealth.jsp Response very slow
> --
>
> Key: HDFS-10246
> URL: https://issues.apache.org/jira/browse/HDFS-10246
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: namenode
>Affects Versions: 2.2.0
> Environment: CentOS6.3 Hadoop-2.2.0
>Reporter: zhangyubiao
> Labels: bug
> Attachments: stacks.txt
>
>
> HDFS Standby NameNode dfshealth.jsp Response very slow
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HDFS-9782) RollingFileSystemSink should have configurable roll interval
[ https://issues.apache.org/jira/browse/HDFS-9782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15221953#comment-15221953 ] Daniel Templeton commented on HDFS-9782: The granularity of the directory names is 1 minute, but that doesn't require that the interval have a 1-minute granularity. I was thinking of the case of a 90-second interval. If you think that has the potential to create confusion, I can drop seconds from the allowed units. > RollingFileSystemSink should have configurable roll interval > > > Key: HDFS-9782 > URL: https://issues.apache.org/jira/browse/HDFS-9782 > Project: Hadoop HDFS > Issue Type: Improvement >Reporter: Daniel Templeton >Assignee: Daniel Templeton > Attachments: HDFS-9782.001.patch, HDFS-9782.002.patch, > HDFS-9782.003.patch, HDFS-9782.004.patch, HDFS-9782.005.patch, > HDFS-9782.006.patch > > > Right now it defaults to rolling at the top of every hour. Instead that > interval should be configurable. The interval should also allow for some > play so that all hosts don't try to flush their files simultaneously. > I'm filing this in HDFS because I suspect it will involve touching the HDFS > tests. If it turns out not to, I'll move it into common instead. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HDFS-10208) Addendum for HDFS-9579: to handle the case when client machine can't resolve network path
[
https://issues.apache.org/jira/browse/HDFS-10208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ming Ma updated HDFS-10208:
---
Attachment: HDFS-10208-3.patch
Thanks [~brahmareddy]. I have updated the property description in
core-default.xml.
>From the investigation of HDFS-10206, the current way of using Topology tree
>to compute node distance by reference seems too expensive. It means it needs
>to add nodes to the Topology tree first which could become slow as the tree
>grows. It also means the tree size could grow unbounded. To solve this issue,
>we can use network path string comparison instead without Topology tree and
>the extra HashMap in ClientContext.
So in summary, the patch has three improvements:
* Handle the case the client can't resolve network path properly.
* Make the client-side topology resolution optional.
* Use string based comparison for network distance calculation.
> Addendum for HDFS-9579: to handle the case when client machine can't resolve
> network path
> -
>
> Key: HDFS-10208
> URL: https://issues.apache.org/jira/browse/HDFS-10208
> Project: Hadoop HDFS
> Issue Type: Bug
>Reporter: Ming Ma
>Assignee: Ming Ma
> Attachments: HDFS-10208-2.patch, HDFS-10208-3.patch, HDFS-10208.patch
>
>
> If DFSClient runs on a machine that can't resolve network path,
> e.g.{{dnsToSwitchMapping.resolve}} returns null, that will cause exception
> when it tries to create {{clientNode}}. In such case, there is no need to
> create {{clientNode}} as null {{clientNode}} means its network distance with
> any datanode is Integer.MAX_VALUE, which is what we want.
> {noformat}
> clientNode = new NodeBase(clientHostName,
> dnsToSwitchMapping.resolve(nodes).get(0));
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HDFS-9782) RollingFileSystemSink should have configurable roll interval
[ https://issues.apache.org/jira/browse/HDFS-9782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karthik Kambatla updated HDFS-9782: --- Status: Open (was: Patch Available) > RollingFileSystemSink should have configurable roll interval > > > Key: HDFS-9782 > URL: https://issues.apache.org/jira/browse/HDFS-9782 > Project: Hadoop HDFS > Issue Type: Improvement >Reporter: Daniel Templeton >Assignee: Daniel Templeton > Attachments: HDFS-9782.001.patch, HDFS-9782.002.patch, > HDFS-9782.003.patch, HDFS-9782.004.patch, HDFS-9782.005.patch, > HDFS-9782.006.patch > > > Right now it defaults to rolling at the top of every hour. Instead that > interval should be configurable. The interval should also allow for some > play so that all hosts don't try to flush their files simultaneously. > I'm filing this in HDFS because I suspect it will involve touching the HDFS > tests. If it turns out not to, I'll move it into common instead. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HDFS-9782) RollingFileSystemSink should have configurable roll interval
[ https://issues.apache.org/jira/browse/HDFS-9782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15221914#comment-15221914 ] Karthik Kambatla commented on HDFS-9782: Quickly skimmed through the patch. One major comment: if we want to support only minute granularity for this, why allow users to specify seconds? The offset milliseconds sounds okay, because the purpose is different. > RollingFileSystemSink should have configurable roll interval > > > Key: HDFS-9782 > URL: https://issues.apache.org/jira/browse/HDFS-9782 > Project: Hadoop HDFS > Issue Type: Improvement >Reporter: Daniel Templeton >Assignee: Daniel Templeton > Attachments: HDFS-9782.001.patch, HDFS-9782.002.patch, > HDFS-9782.003.patch, HDFS-9782.004.patch, HDFS-9782.005.patch, > HDFS-9782.006.patch > > > Right now it defaults to rolling at the top of every hour. Instead that > interval should be configurable. The interval should also allow for some > play so that all hosts don't try to flush their files simultaneously. > I'm filing this in HDFS because I suspect it will involve touching the HDFS > tests. If it turns out not to, I'll move it into common instead. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HDFS-10247) libhdfs++: Datanode protocol version mismatch
James Clampffer created HDFS-10247:
--
Summary: libhdfs++: Datanode protocol version mismatch
Key: HDFS-10247
URL: https://issues.apache.org/jira/browse/HDFS-10247
Project: Hadoop HDFS
Issue Type: Sub-task
Reporter: James Clampffer
Assignee: James Clampffer
Occasionally "Version Mismatch (Expected: 28, Received: 22794 )" shows up in
the logs. This doesn't happen much at all with less than 500 concurrent reads
and starts happening often enough to be an issue at 1000 concurrent reads.
I've seen 3 distinct numbers: 23050 (most common), 22538, and 22794. If you
break these shorts into bytes you get
{code}
23050 -> [90,10]
22794 -> [89,10]
22538 -> [88,10]
{code}
Interestingly enough if we dump buffers holding protobuf messages just before
they hit the wire we see things like the following with the first two bytes as
90,10
{code}
buffer
={90,10,82,10,64,10,52,10,37,66,80,45,49,51,56,49,48,51,51,57,57,49,45,49,50,55,46,48,46,48,46,49,45,49,52,53,57,53,50,53,54,49,53,55,50,53,16,-127,-128,-128,-128,4,24,-23,7,32,-128,-128,64,18,8,10,0,18,0,26,0,34,0,18,14,108,105,98,104,100,102,115,43,43,95,75,67,43,49,16,0,24,23,32,1}
{code}
The first 3 bytes the DN is expecting for an unsecured read block request =
{code}
{0,28,81} //[0, 28]->a short for protocol, 81 is read block opcode
{code}
This seems like either connections are getting swapped between readers or
the header isn't being sent for some reason but the protobuf message is.
I've ruled out memory stomps on the header data (see HDFS-10241) by sticking
the 3 byte header in it's own static buffer that all requests use.
Some notes:
-The mismatched number will stay the same for the duration of a stress test.
-The mismatch is distributed fairly evenly throughout the logs
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HDFS-10246) HDFS Standby NameNode dfshealth.jsp Response very slow
[ https://issues.apache.org/jira/browse/HDFS-10246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15221814#comment-15221814 ] zhangyubiao commented on HDFS-10246: [~vinayrpet] I konw the latest versions of hadoop replaced by new HTML5 webUI dfshealth.html . But We still use Hadoop-2.2.0. We open the jmx metrics and find it very slow too. And sometimes the Active NameNode lost the node and recorvery in a few times . I update the stacks for Standby NameNode > HDFS Standby NameNode dfshealth.jsp Response very slow > -- > > Key: HDFS-10246 > URL: https://issues.apache.org/jira/browse/HDFS-10246 > Project: Hadoop HDFS > Issue Type: Bug > Components: namenode >Affects Versions: 2.2.0 > Environment: CentOS6.3 Hadoop-2.2.0 >Reporter: zhangyubiao > Labels: bug > Attachments: stacks.txt > > > HDFS Standby NameNode dfshealth.jsp Response very slow -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HDFS-10237) Support specifying checksum type in WebHDFS/HTTPFS writers
[ https://issues.apache.org/jira/browse/HDFS-10237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Harsh J updated HDFS-10237: --- Status: Open (was: Patch Available) > Support specifying checksum type in WebHDFS/HTTPFS writers > -- > > Key: HDFS-10237 > URL: https://issues.apache.org/jira/browse/HDFS-10237 > Project: Hadoop HDFS > Issue Type: New Feature > Components: webhdfs >Affects Versions: 2.8.0 >Reporter: Harsh J >Assignee: Harsh J >Priority: Minor > Attachments: HDFS-10237.000.patch, HDFS-10237.001.patch, > HDFS-10237.002.patch > > > Currently you cannot set a desired checksum type over a WebHDFS or HTTPFS > writer, as you can with the regular DFS writer (done via HADOOP-8240) > This JIRA covers the changes necessary to bring the same ability to WebHDFS > and HTTPFS. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HDFS-10237) Support specifying checksum type in WebHDFS/HTTPFS writers
[ https://issues.apache.org/jira/browse/HDFS-10237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Harsh J updated HDFS-10237: --- Status: Patch Available (was: Open) > Support specifying checksum type in WebHDFS/HTTPFS writers > -- > > Key: HDFS-10237 > URL: https://issues.apache.org/jira/browse/HDFS-10237 > Project: Hadoop HDFS > Issue Type: New Feature > Components: webhdfs >Affects Versions: 2.8.0 >Reporter: Harsh J >Assignee: Harsh J >Priority: Minor > Attachments: HDFS-10237.000.patch, HDFS-10237.001.patch, > HDFS-10237.002.patch > > > Currently you cannot set a desired checksum type over a WebHDFS or HTTPFS > writer, as you can with the regular DFS writer (done via HADOOP-8240) > This JIRA covers the changes necessary to bring the same ability to WebHDFS > and HTTPFS. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HDFS-10246) HDFS Standby NameNode dfshealth.jsp Response very slow
[
https://issues.apache.org/jira/browse/HDFS-10246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15221805#comment-15221805
]
Vinayakumar B commented on HDFS-10246:
--
[~piaoyu zhang], In latest versions of hadoop. {{dfshealth.jsp}} has been
replaced by new HTML5 webUI {{dfshealth.html}}
Where page will load without any hiccups. Its completely lockless and works
entirely on basis of JMX metrics.
> HDFS Standby NameNode dfshealth.jsp Response very slow
> --
>
> Key: HDFS-10246
> URL: https://issues.apache.org/jira/browse/HDFS-10246
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: namenode
>Affects Versions: 2.2.0
> Environment: CentOS6.3 Hadoop-2.2.0
>Reporter: zhangyubiao
> Labels: bug
> Attachments: stacks.txt
>
>
> HDFS Standby NameNode dfshealth.jsp Response very slow
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HDFS-10246) HDFS Standby NameNode dfshealth.jsp Response very slow
[ https://issues.apache.org/jira/browse/HDFS-10246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15221798#comment-15221798 ] zhangyubiao commented on HDFS-10246: [~mingma] Is it the same as https://issues.apache.org/jira/browse/HDFS-7609 , Would you like give a look ? > HDFS Standby NameNode dfshealth.jsp Response very slow > -- > > Key: HDFS-10246 > URL: https://issues.apache.org/jira/browse/HDFS-10246 > Project: Hadoop HDFS > Issue Type: Bug > Components: namenode >Affects Versions: 2.2.0 > Environment: CentOS6.3 Hadoop-2.2.0 >Reporter: zhangyubiao > Labels: bug > Attachments: stacks.txt > > > HDFS Standby NameNode dfshealth.jsp Response very slow -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HDFS-10246) HDFS Standby NameNode dfshealth.jsp Response very slow
[ https://issues.apache.org/jira/browse/HDFS-10246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] zhangyubiao updated HDFS-10246: --- Attachment: stacks.txt > HDFS Standby NameNode dfshealth.jsp Response very slow > -- > > Key: HDFS-10246 > URL: https://issues.apache.org/jira/browse/HDFS-10246 > Project: Hadoop HDFS > Issue Type: Bug > Components: namenode >Affects Versions: 2.2.0 > Environment: CentOS6.3 Hadoop-2.2.0 >Reporter: zhangyubiao > Labels: bug > Attachments: stacks.txt > > > HDFS Standby NameNode dfshealth.jsp Response very slow -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HDFS-10246) HDFS Standby NameNode dfshealth.jsp Response very slow
zhangyubiao created HDFS-10246: -- Summary: HDFS Standby NameNode dfshealth.jsp Response very slow Key: HDFS-10246 URL: https://issues.apache.org/jira/browse/HDFS-10246 Project: Hadoop HDFS Issue Type: Bug Components: namenode Affects Versions: 2.2.0 Environment: CentOS6.3 Hadoop-2.2.0 Reporter: zhangyubiao HDFS Standby NameNode dfshealth.jsp Response very slow -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HDFS-10245) Fix the findbug warnings in branch-2.7
[
https://issues.apache.org/jira/browse/HDFS-10245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brahma Reddy Battula updated HDFS-10245:
Affects Version/s: 2.7.2
> Fix the findbug warnings in branch-2.7
> --
>
> Key: HDFS-10245
> URL: https://issues.apache.org/jira/browse/HDFS-10245
> Project: Hadoop HDFS
> Issue Type: Bug
>Affects Versions: 2.7.2
>Reporter: Brahma Reddy Battula
>Assignee: Brahma Reddy Battula
>
> *Link*
> https://builds.apache.org/job/PreCommit-HDFS-Build/15036/artifact/patchprocess/branch-findbugs-hadoop-hdfs-project_hadoop-hdfs-warnings.html
> Following seen in HDFS-9917 jenkins run.
> {noformat}
> Code Warning
> ISInconsistent synchronization of
> org.apache.hadoop.hdfs.DFSOutputStream.streamer; locked 85% of time
> Bug type IS2_INCONSISTENT_SYNC (click for details)
> In class org.apache.hadoop.hdfs.DFSOutputStream
> Field org.apache.hadoop.hdfs.DFSOutputStream.streamer
> Synchronized 85% of the time
> Unsynchronized access at DFSOutputStream.java:[line 2372]
> Unsynchronized access at DFSOutputStream.java:[line 2390]
> Unsynchronized access at DFSOutputStream.java:[line 1722]
> Synchronized access at DFSOutputStream.java:[line 2178]
> Synchronized access at DFSOutputStream.java:[line 2100]
> Synchronized access at DFSOutputStream.java:[line 2103]
> Synchronized access at DFSOutputStream.java:[line 2264]
> Synchronized access at DFSOutputStream.java:[line 1555]
> Synchronized access at DFSOutputStream.java:[line 1558]
> Synchronized access at DFSOutputStream.java:[line 2166]
> Synchronized access at DFSOutputStream.java:[line 2208]
> Synchronized access at DFSOutputStream.java:[line 2216]
> Synchronized access at DFSOutputStream.java:[line 2209]
> Synchronized access at DFSOutputStream.java:[line 2216]
> Synchronized access at DFSOutputStream.java:[line 2037]
> Synchronized access at DFSOutputStream.java:[line 2037]
> Synchronized access at DFSOutputStream.java:[line 2038]
> Synchronized access at DFSOutputStream.java:[line 2062]
> Synchronized access at DFSOutputStream.java:[line 2063]
> Synchronized access at DFSOutputStream.java:[line 2355]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (HDFS-10245) Fix the findbug warnings in branch-2.7
Brahma Reddy Battula created HDFS-10245:
---
Summary: Fix the findbug warnings in branch-2.7
Key: HDFS-10245
URL: https://issues.apache.org/jira/browse/HDFS-10245
Project: Hadoop HDFS
Issue Type: Bug
Reporter: Brahma Reddy Battula
Assignee: Brahma Reddy Battula
*Link*
https://builds.apache.org/job/PreCommit-HDFS-Build/15036/artifact/patchprocess/branch-findbugs-hadoop-hdfs-project_hadoop-hdfs-warnings.html
Following seen in HDFS-9917 jenkins run.
{noformat}
CodeWarning
IS Inconsistent synchronization of
org.apache.hadoop.hdfs.DFSOutputStream.streamer; locked 85% of time
Bug type IS2_INCONSISTENT_SYNC (click for details)
In class org.apache.hadoop.hdfs.DFSOutputStream
Field org.apache.hadoop.hdfs.DFSOutputStream.streamer
Synchronized 85% of the time
Unsynchronized access at DFSOutputStream.java:[line 2372]
Unsynchronized access at DFSOutputStream.java:[line 2390]
Unsynchronized access at DFSOutputStream.java:[line 1722]
Synchronized access at DFSOutputStream.java:[line 2178]
Synchronized access at DFSOutputStream.java:[line 2100]
Synchronized access at DFSOutputStream.java:[line 2103]
Synchronized access at DFSOutputStream.java:[line 2264]
Synchronized access at DFSOutputStream.java:[line 1555]
Synchronized access at DFSOutputStream.java:[line 1558]
Synchronized access at DFSOutputStream.java:[line 2166]
Synchronized access at DFSOutputStream.java:[line 2208]
Synchronized access at DFSOutputStream.java:[line 2216]
Synchronized access at DFSOutputStream.java:[line 2209]
Synchronized access at DFSOutputStream.java:[line 2216]
Synchronized access at DFSOutputStream.java:[line 2037]
Synchronized access at DFSOutputStream.java:[line 2037]
Synchronized access at DFSOutputStream.java:[line 2038]
Synchronized access at DFSOutputStream.java:[line 2062]
Synchronized access at DFSOutputStream.java:[line 2063]
Synchronized access at DFSOutputStream.java:[line 2355]
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HDFS-10243) When using the TableMapping network topology, adding new datanoe need to restart the namenode
[
https://issues.apache.org/jira/browse/HDFS-10243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15221779#comment-15221779
]
Vinayakumar B commented on HDFS-10243:
--
{{dnsToSwitchMapping.reloadCachedMappings(invalidNodeNames);}} will be called
only when the resolved values are at different levels.
In your case, already exist nodes have 2 level mapping. switch and rack. But
new node is getting resolved to default value of just rack level. So
{{InvalidTopologyException}} will come, in which case. Patch proposed will
reload the contents.
But, if original mappings in the file are also at 1 level (rack), then patch
will have no effect.
How about loading the file, during resolve itself?
Below changes will reload everytime a unresolved and uncached node is trying to
resolve.
{code}
@@ -133,14 +137,22 @@ public void reloadCachedMappings() {
map = new HashMap();
}
}
+ boolean justLoaded = false;
List results = new ArrayList(names.size());
for (String name : names) {
String result = map.get(name);
-if (result != null) {
- results.add(result);
-} else {
- results.add(NetworkTopology.DEFAULT_RACK);
+if (result == null) {
+ // try to re-load map, if not recently loaded.
+ if (!justLoaded) {
+map = load();
+justLoaded = true;
+result = map.get(name);
+ }
+ if (result == null) {
+result = NetworkTopology.DEFAULT_RACK;
+ }
}
+results.add(result);
}
return results;
}
{code}
> When using the TableMapping network topology, adding new datanoe need to
> restart the namenode
> -
>
> Key: HDFS-10243
> URL: https://issues.apache.org/jira/browse/HDFS-10243
> Project: Hadoop HDFS
> Issue Type: Bug
> Environment: 2.6.0
>Reporter: shenxianqiang
>Priority: Minor
> Attachments: HDFS-10243.patch
>
>
> When I use the TableMapping network topology, adding new machines need to
> restart the namenode. Configure :
> {quote}
>
> net.topology.node.switch.mapping.impl
> org.apache.hadoop.net.TableMapping
>
>
> net.topology.table.file.name
> /etc/hadoop/conf/net_topology_table
>
> {quote}
> In /etc/hadoop/conf/net_topology_table:
> {quote}
> 10.0.0.1 /SJS/SJS-1
> 10.0.0.2 /CTC/CTC-2
> 10.0.0.3 /TC/TC-3
> {quote}
> When I add a new datanode like 10.0.0.4 /SJS/SJS-2,datanode throw exception:
> {quote}
> 2016-03-30 17:11:15,608 ERROR
> org.apache.hadoop.hdfs.server.datanode.DataNode: Initialization failed for
> Block pool BP-408802935-10.0.0.100-1402130194887 (Datanode Uuid null) service
> to nn1/10.0.0.100:8020 Failed to add /default-rack/10.0.0.4:50010: You cannot
> have a rack and a non-rack node at the same level of the network topology.
> at org.apache.hadoop.net.NetworkTopology.add(NetworkTopology.java:408)
> at
> org.apache.hadoop.hdfs.server.blockmanagement.DatanodeManager.registerDatanode(DatanodeManager.java:1001)
> at
> org.apache.hadoop.hdfs.server.namenode.FSNamesystem.registerDatanode(FSNamesystem.java:4837)
> at
> org.apache.hadoop.hdfs.server.namenode.NameNodeRpcServer.registerDatanode(NameNodeRpcServer.java:1038)
> at
> org.apache.hadoop.hdfs.protocolPB.DatanodeProtocolServerSideTranslatorPB.registerDatanode(DatanodeProtocolServerSideTranslatorPB.java:92)
> at
> org.apache.hadoop.hdfs.protocol.proto.DatanodeProtocolProtos$DatanodeProtocolService$2.callBlockingMethod(DatanodeProtocolProtos.java:26378)
> at
> org.apache.hadoop.ipc.ProtobufRpcEngine$Server$ProtoBufRpcInvoker.call(ProtobufRpcEngine.java:587)
> at org.apache.hadoop.ipc.RPC$Server.call(RPC.java:1026)
> at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:2013)
> at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:2009)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:415)
> at
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1892)
> at org.apache.hadoop.ipc.Server$Handler.run(Server.java:2007)
> {quote}
> I need to update /etc/hadoop/conf/net_topology_table,and restart
> namenode.After that,the new datanode should work.
> Restart Namenode may cause a bad influence.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HDFS-10243) When using the TableMapping network topology, adding new datanoe need to restart the namenode
[
https://issues.apache.org/jira/browse/HDFS-10243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15221741#comment-15221741
]
Hadoop QA commented on HDFS-10243:
--
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 10s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s {color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 6m
30s {color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 5m 46s
{color} | {color:green} trunk passed with JDK v1.8.0_77 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 6m 40s
{color} | {color:green} trunk passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
20s {color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 56s
{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
13s {color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
33s {color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 53s
{color} | {color:green} trunk passed with JDK v1.8.0_77 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 2s
{color} | {color:green} trunk passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
40s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 5m 42s
{color} | {color:green} the patch passed with JDK v1.8.0_77 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 5m 42s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 6m 37s
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 6m 37s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
20s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 56s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
13s {color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} whitespace {color} | {color:red} 0m 0s
{color} | {color:red} The patch has 2 line(s) that end in whitespace. Use git
apply --whitespace=fix. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
47s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 53s
{color} | {color:green} the patch passed with JDK v1.8.0_77 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 2s
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 7m 48s
{color} | {color:green} hadoop-common in the patch passed with JDK v1.8.0_77.
{color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 7m 57s
{color} | {color:green} hadoop-common in the patch passed with JDK v1.7.0_95.
{color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
21s {color} | {color:green} Patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 59m 28s {color}
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Image:yetus/hadoop:fbe3e86 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12796521/HDFS-10243.patch |
| JIRA Issue | HDFS-10243 |
| Optional Tests | asflicense compile javac javadoc mvninstall mvnsite
unit findbugs checkstyle |
| uname | Linux 080e61157502 3.13.0-36-lowlatency #63-Ubuntu SMP PREEMPT Wed
Sep 3 21:56:12 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality | /testptch/hadoop/patchprocess/precommit/personality/provided.sh
|
| git revision | trunk / 256c82f |
| Default Java | 1.7.0_95 |
| Multi-JDK
[jira] [Commented] (HDFS-9917) IBR accumulate more objects when SNN was down for sometime.
[
https://issues.apache.org/jira/browse/HDFS-9917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15221704#comment-15221704
]
Hadoop QA commented on HDFS-9917:
-
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 8m 17s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s {color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 7m
32s {color} | {color:green} branch-2.7 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 3s
{color} | {color:green} branch-2.7 passed with JDK v1.8.0_77 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 59s
{color} | {color:green} branch-2.7 passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
26s {color} | {color:green} branch-2.7 passed {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 59s
{color} | {color:green} branch-2.7 passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
17s {color} | {color:green} branch-2.7 passed {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 3m 2s
{color} | {color:red} hadoop-hdfs-project/hadoop-hdfs in branch-2.7 has 1
extant Findbugs warnings. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 10s
{color} | {color:green} branch-2.7 passed with JDK v1.8.0_77 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 54s
{color} | {color:green} branch-2.7 passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
52s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 54s
{color} | {color:green} the patch passed with JDK v1.8.0_77 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 54s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 57s
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 57s
{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 0m 21s
{color} | {color:red} hadoop-hdfs-project/hadoop-hdfs: patch generated 1 new +
33 unchanged - 0 fixed = 34 total (was 33) {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 54s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
11s {color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} whitespace {color} | {color:red} 0m 0s
{color} | {color:red} The patch has 1732 line(s) that end in whitespace. Use
git apply --whitespace=fix. {color} |
| {color:red}-1{color} | {color:red} whitespace {color} | {color:red} 0m 44s
{color} | {color:red} The patch has 250 line(s) with tabs. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m 5s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 5s
{color} | {color:green} the patch passed with JDK v1.8.0_77 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 53s
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 44m 33s {color}
| {color:red} hadoop-hdfs in the patch failed with JDK v1.8.0_77. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 43m 15s {color}
| {color:red} hadoop-hdfs in the patch failed with JDK v1.7.0_95. {color} |
| {color:red}-1{color} | {color:red} asflicense {color} | {color:red} 1m 8s
{color} | {color:red} Patch generated 65 ASF License warnings. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 128m 5s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| JDK v1.8.0_77 Failed junit tests | hadoop.hdfs.TestDatanodeRegistration |
| | hadoop.tools.TestJMXGet |
| | hadoop.hdfs.server.balancer.TestBalancer |
| | hadoop.hdfs.server.datanode.TestDataNodeMetrics |
| | hadoop.hdfs.TestHFlush |
| | hadoop.hdfs.server.namenode.snapshot.TestRenameWithSnapshots |
| JD
[jira] [Updated] (HDFS-10243) When using the TableMapping network topology, adding new datanoe need to restart the namenode
[
https://issues.apache.org/jira/browse/HDFS-10243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
shenxianqiang updated HDFS-10243:
-
Status: Patch Available (was: Open)
> When using the TableMapping network topology, adding new datanoe need to
> restart the namenode
> -
>
> Key: HDFS-10243
> URL: https://issues.apache.org/jira/browse/HDFS-10243
> Project: Hadoop HDFS
> Issue Type: Bug
> Environment: 2.6.0
>Reporter: shenxianqiang
>Priority: Minor
> Attachments: HDFS-10243.patch
>
>
> When I use the TableMapping network topology, adding new machines need to
> restart the namenode. Configure :
> {quote}
>
> net.topology.node.switch.mapping.impl
> org.apache.hadoop.net.TableMapping
>
>
> net.topology.table.file.name
> /etc/hadoop/conf/net_topology_table
>
> {quote}
> In /etc/hadoop/conf/net_topology_table:
> {quote}
> 10.0.0.1 /SJS/SJS-1
> 10.0.0.2 /CTC/CTC-2
> 10.0.0.3 /TC/TC-3
> {quote}
> When I add a new datanode like 10.0.0.4 /SJS/SJS-2,datanode throw exception:
> {quote}
> 2016-03-30 17:11:15,608 ERROR
> org.apache.hadoop.hdfs.server.datanode.DataNode: Initialization failed for
> Block pool BP-408802935-10.0.0.100-1402130194887 (Datanode Uuid null) service
> to nn1/10.0.0.100:8020 Failed to add /default-rack/10.0.0.4:50010: You cannot
> have a rack and a non-rack node at the same level of the network topology.
> at org.apache.hadoop.net.NetworkTopology.add(NetworkTopology.java:408)
> at
> org.apache.hadoop.hdfs.server.blockmanagement.DatanodeManager.registerDatanode(DatanodeManager.java:1001)
> at
> org.apache.hadoop.hdfs.server.namenode.FSNamesystem.registerDatanode(FSNamesystem.java:4837)
> at
> org.apache.hadoop.hdfs.server.namenode.NameNodeRpcServer.registerDatanode(NameNodeRpcServer.java:1038)
> at
> org.apache.hadoop.hdfs.protocolPB.DatanodeProtocolServerSideTranslatorPB.registerDatanode(DatanodeProtocolServerSideTranslatorPB.java:92)
> at
> org.apache.hadoop.hdfs.protocol.proto.DatanodeProtocolProtos$DatanodeProtocolService$2.callBlockingMethod(DatanodeProtocolProtos.java:26378)
> at
> org.apache.hadoop.ipc.ProtobufRpcEngine$Server$ProtoBufRpcInvoker.call(ProtobufRpcEngine.java:587)
> at org.apache.hadoop.ipc.RPC$Server.call(RPC.java:1026)
> at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:2013)
> at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:2009)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:415)
> at
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1892)
> at org.apache.hadoop.ipc.Server$Handler.run(Server.java:2007)
> {quote}
> I need to update /etc/hadoop/conf/net_topology_table,and restart
> namenode.After that,the new datanode should work.
> Restart Namenode may cause a bad influence.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HDFS-10243) When using the TableMapping network topology, adding new datanoe need to restart the namenode
[
https://issues.apache.org/jira/browse/HDFS-10243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
shenxianqiang updated HDFS-10243:
-
Attachment: HDFS-10243.patch
Because registerDatanode call
dnsToSwitchMapping.reloadCachedMappings(invalidNodeNames),so I think only
override reloadCachedMappings(invalidNodeNames).Please help to review.
> When using the TableMapping network topology, adding new datanoe need to
> restart the namenode
> -
>
> Key: HDFS-10243
> URL: https://issues.apache.org/jira/browse/HDFS-10243
> Project: Hadoop HDFS
> Issue Type: Bug
> Environment: 2.6.0
>Reporter: shenxianqiang
>Priority: Minor
> Attachments: HDFS-10243.patch
>
>
> When I use the TableMapping network topology, adding new machines need to
> restart the namenode. Configure :
> {quote}
>
> net.topology.node.switch.mapping.impl
> org.apache.hadoop.net.TableMapping
>
>
> net.topology.table.file.name
> /etc/hadoop/conf/net_topology_table
>
> {quote}
> In /etc/hadoop/conf/net_topology_table:
> {quote}
> 10.0.0.1 /SJS/SJS-1
> 10.0.0.2 /CTC/CTC-2
> 10.0.0.3 /TC/TC-3
> {quote}
> When I add a new datanode like 10.0.0.4 /SJS/SJS-2,datanode throw exception:
> {quote}
> 2016-03-30 17:11:15,608 ERROR
> org.apache.hadoop.hdfs.server.datanode.DataNode: Initialization failed for
> Block pool BP-408802935-10.0.0.100-1402130194887 (Datanode Uuid null) service
> to nn1/10.0.0.100:8020 Failed to add /default-rack/10.0.0.4:50010: You cannot
> have a rack and a non-rack node at the same level of the network topology.
> at org.apache.hadoop.net.NetworkTopology.add(NetworkTopology.java:408)
> at
> org.apache.hadoop.hdfs.server.blockmanagement.DatanodeManager.registerDatanode(DatanodeManager.java:1001)
> at
> org.apache.hadoop.hdfs.server.namenode.FSNamesystem.registerDatanode(FSNamesystem.java:4837)
> at
> org.apache.hadoop.hdfs.server.namenode.NameNodeRpcServer.registerDatanode(NameNodeRpcServer.java:1038)
> at
> org.apache.hadoop.hdfs.protocolPB.DatanodeProtocolServerSideTranslatorPB.registerDatanode(DatanodeProtocolServerSideTranslatorPB.java:92)
> at
> org.apache.hadoop.hdfs.protocol.proto.DatanodeProtocolProtos$DatanodeProtocolService$2.callBlockingMethod(DatanodeProtocolProtos.java:26378)
> at
> org.apache.hadoop.ipc.ProtobufRpcEngine$Server$ProtoBufRpcInvoker.call(ProtobufRpcEngine.java:587)
> at org.apache.hadoop.ipc.RPC$Server.call(RPC.java:1026)
> at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:2013)
> at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:2009)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:415)
> at
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1892)
> at org.apache.hadoop.ipc.Server$Handler.run(Server.java:2007)
> {quote}
> I need to update /etc/hadoop/conf/net_topology_table,and restart
> namenode.After that,the new datanode should work.
> Restart Namenode may cause a bad influence.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HDFS-10242) Space Quota of zero behaves different from documentation.
[
https://issues.apache.org/jira/browse/HDFS-10242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15221584#comment-15221584
]
Hadoop QA commented on HDFS-10242:
--
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 17s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s {color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 36s
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 7m
30s {color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 8m 46s
{color} | {color:green} trunk passed with JDK v1.8.0_74 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 7m 48s
{color} | {color:green} trunk passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
10s {color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 2m 37s
{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
40s {color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 5m
36s {color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m 46s
{color} | {color:green} trunk passed with JDK v1.8.0_74 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 3m 37s
{color} | {color:green} trunk passed with JDK v1.7.0_95 {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 16s
{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 2m
17s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 8m 48s
{color} | {color:green} the patch passed with JDK v1.8.0_74 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 8m 48s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 7m 53s
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 7m 53s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
9s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 2m 37s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
38s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 6m
13s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m 47s
{color} | {color:green} the patch passed with JDK v1.8.0_74 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 3m 38s
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 9m 40s {color}
| {color:red} hadoop-common in the patch failed with JDK v1.8.0_74. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 5s
{color} | {color:green} hadoop-hdfs-client in the patch passed with JDK
v1.8.0_74. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 87m 5s {color}
| {color:red} hadoop-hdfs in the patch failed with JDK v1.8.0_74. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 9m 52s
{color} | {color:green} hadoop-common in the patch passed with JDK v1.7.0_95.
{color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 2s
{color} | {color:green} hadoop-hdfs-client in the patch passed with JDK
v1.7.0_95. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 80m 26s {color}
| {color:red} hadoop-hdfs in the patch failed with JDK v1.7.0_95. {color} |
| {
[jira] [Updated] (HDFS-9917) IBR accumulate more objects when SNN was down for sometime.
[ https://issues.apache.org/jira/browse/HDFS-9917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brahma Reddy Battula updated HDFS-9917: --- Attachment: HDFS-9917-branch-2.7.patch HDFS-9917-02.patch bq. Please file a follow up jira for the "Avoid accumulation of IBRs for SNN when the standby is down for more than expected time". Raised HDFS-10244. bq. Seeing the criticality of this issue, I feel it would be better to land this in 2.7.3 with reRegister() IBR clearance fix. Uploaded the patch ..Kindly Review. > IBR accumulate more objects when SNN was down for sometime. > --- > > Key: HDFS-9917 > URL: https://issues.apache.org/jira/browse/HDFS-9917 > Project: Hadoop HDFS > Issue Type: Bug >Affects Versions: 2.7.2 >Reporter: Brahma Reddy Battula >Assignee: Brahma Reddy Battula >Priority: Critical > Attachments: HDFS-9917-02.patch, HDFS-9917-branch-2.7.patch, > HDFS-9917.patch > > > SNN was down for sometime because of some reasons..After restarting SNN,it > became unreponsive because > - 29 DN's sending IBR in each 5 million ( most of them are delete IBRs), > where as each datanode had only ~2.5 million blocks. > - GC can't trigger on this objects since all will be under RPC queue. > To recover this( to clear this objects) ,restarted all the DN's one by > one..This issue happened in 2.4.1 where split of blockreport was not > available. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HDFS-10244) Avoid accumulation of IBRs for SNN when the standby is down for more than expected time
Brahma Reddy Battula created HDFS-10244: --- Summary: Avoid accumulation of IBRs for SNN when the standby is down for more than expected time Key: HDFS-10244 URL: https://issues.apache.org/jira/browse/HDFS-10244 Project: Hadoop HDFS Issue Type: Bug Reporter: Brahma Reddy Battula Assignee: Brahma Reddy Battula As per discussion in HDFS-9917 and [comment|https://issues.apache.org/jira/browse/HDFS-9917?focusedCommentId=15213947&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15213947] from [~vinayrpet] Avoid accumulation of IBRs when the standby is down for long time, can we consider as below. 1. IBRs for StandbyNN can have a threshold ( say 100K or 1Million IBRs ). 2. Also not to loose any important IBRs, IBRs can be cleared when "the threshold is reached AND 'lastIBR' is more than 'heartbeatExpiryInterval'. i.e. DataNode is considered dead in Namenode side". In that case, for sure re-Register() will be called on reconnection to running NameNode (if any). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HDFS-10238) Ozone : Add chunk persistance
[
https://issues.apache.org/jira/browse/HDFS-10238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15221501#comment-15221501
]
Hadoop QA commented on HDFS-10238:
--
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 11s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s {color} | {color:green} The patch appears to include 4 new or modified test
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 6m
58s {color} | {color:green} HDFS-7240 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 50s
{color} | {color:green} HDFS-7240 passed with JDK v1.8.0_74 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 44s
{color} | {color:green} HDFS-7240 passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
20s {color} | {color:green} HDFS-7240 passed {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 54s
{color} | {color:green} HDFS-7240 passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
13s {color} | {color:green} HDFS-7240 passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
14s {color} | {color:green} HDFS-7240 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 34s
{color} | {color:green} HDFS-7240 passed with JDK v1.8.0_74 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m 37s
{color} | {color:green} HDFS-7240 passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
48s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 38s
{color} | {color:green} the patch passed with JDK v1.8.0_74 {color} |
| {color:green}+1{color} | {color:green} cc {color} | {color:green} 0m 38s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 38s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 40s
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} cc {color} | {color:green} 0m 40s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 40s
{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 0m 19s
{color} | {color:red} hadoop-hdfs-project/hadoop-hdfs: patch generated 1 new +
0 unchanged - 0 fixed = 1 total (was 0) {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 51s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
11s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
27s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 30s
{color} | {color:green} the patch passed with JDK v1.8.0_74 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m 33s
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 55m 1s {color}
| {color:red} hadoop-hdfs in the patch failed with JDK v1.8.0_74. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 53m 3s {color}
| {color:red} hadoop-hdfs in the patch failed with JDK v1.7.0_95. {color} |
| {color:red}-1{color} | {color:red} asflicense {color} | {color:red} 0m 23s
{color} | {color:red} Patch generated 1 ASF License warnings. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 137m 3s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| JDK v1.8.0_74 Failed junit tests |
hadoop.hdfs.server.datanode.fsdataset.impl.TestFsDatasetImpl |
| | hadoop.hdfs.TestHFlush |
| | hadoop.hdfs.server.namenode.ha.TestDFSUpgradeWithHA |
| JDK v1.7.0_95 Failed junit tests |
hadoop.hdfs.server.datanode.fsdataset.impl.TestFsDatasetImpl |
| | hadoop.hdfs.Tes
[jira] [Created] (HDFS-10243) When using the TableMapping network topology, adding new datanoe need to restart the namenode
shenxianqiang created HDFS-10243:
Summary: When using the TableMapping network topology, adding new
datanoe need to restart the namenode
Key: HDFS-10243
URL: https://issues.apache.org/jira/browse/HDFS-10243
Project: Hadoop HDFS
Issue Type: Bug
Environment: 2.6.0
Reporter: shenxianqiang
Priority: Minor
When I use the TableMapping network topology, adding new machines need to
restart the namenode. Configure :
{quote}
net.topology.node.switch.mapping.impl
org.apache.hadoop.net.TableMapping
net.topology.table.file.name
/etc/hadoop/conf/net_topology_table
{quote}
In /etc/hadoop/conf/net_topology_table:
{quote}
10.0.0.1 /SJS/SJS-1
10.0.0.2 /CTC/CTC-2
10.0.0.3 /TC/TC-3
{quote}
When I add a new datanode like 10.0.0.4 /SJS/SJS-2,datanode throw exception:
{quote}
2016-03-30 17:11:15,608 ERROR org.apache.hadoop.hdfs.server.datanode.DataNode:
Initialization failed for Block pool BP-408802935-10.0.0.100-1402130194887
(Datanode Uuid null) service to nn1/10.0.0.100:8020 Failed to add
/default-rack/10.0.0.4:50010: You cannot have a rack and a non-rack node at the
same level of the network topology.
at org.apache.hadoop.net.NetworkTopology.add(NetworkTopology.java:408)
at
org.apache.hadoop.hdfs.server.blockmanagement.DatanodeManager.registerDatanode(DatanodeManager.java:1001)
at
org.apache.hadoop.hdfs.server.namenode.FSNamesystem.registerDatanode(FSNamesystem.java:4837)
at
org.apache.hadoop.hdfs.server.namenode.NameNodeRpcServer.registerDatanode(NameNodeRpcServer.java:1038)
at
org.apache.hadoop.hdfs.protocolPB.DatanodeProtocolServerSideTranslatorPB.registerDatanode(DatanodeProtocolServerSideTranslatorPB.java:92)
at
org.apache.hadoop.hdfs.protocol.proto.DatanodeProtocolProtos$DatanodeProtocolService$2.callBlockingMethod(DatanodeProtocolProtos.java:26378)
at
org.apache.hadoop.ipc.ProtobufRpcEngine$Server$ProtoBufRpcInvoker.call(ProtobufRpcEngine.java:587)
at org.apache.hadoop.ipc.RPC$Server.call(RPC.java:1026)
at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:2013)
at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:2009)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:415)
at
org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1892)
at org.apache.hadoop.ipc.Server$Handler.run(Server.java:2007)
{quote}
I need to update /etc/hadoop/conf/net_topology_table,and restart namenode.After
that,the new datanode should work.
Restart Namenode may cause a bad influence.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
