[
https://issues.apache.org/jira/browse/HDFS-7603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14277062#comment-14277062
]
Kihwal Lee commented on HDFS-7603:
----------------------------------
The test failure is unrelated, but looks bad. Bus errors usually happen with a
library mix-up.
{noformat}
Results :
Tests run: 2428, Failures: 0, Errors: 0, Skipped: 13
...
Running org.apache.hadoop.hdfs.qjournal.client.TestQJMWithFaults
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGBUS (0x7) at pc=0x00007f8447de9982, pid=3045, tid=140206235416320
#
# JRE version: Java(TM) SE Runtime Environment (7.0_55-b13) (build 1.7.0_55-b13)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (24.55-b03 mixed mode linux-amd64
compressed oops)
# Problematic frame:
# C [libzip.so+0x4982] newEntry+0x62
#
# Failed to write core dump. Core dumps have been disabled. To enable core
dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
#
/home/jenkins/jenkins-slave/workspace/PreCommit-HDFS-Build@2/hadoop-hdfs-project/hadoop-hdfs/hs_err_pid3045.log
Compiled method (nm) 119738 46 n java.util.zip.ZipFile::getEntry
(native)
total in heap [0x00007f8444e5b450,0x00007f8444e5b7e8] = 920
relocation [0x00007f8444e5b570,0x00007f8444e5b5d0] = 96
main code [0x00007f8444e5b5e0,0x00007f8444e5b7e8] = 520
#
# If you would like to submit a bug report, please visit:
# http://bugreport.sun.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
Aborted
{noformat}
> The background replication queue initialization may not let others run
> ----------------------------------------------------------------------
>
> Key: HDFS-7603
> URL: https://issues.apache.org/jira/browse/HDFS-7603
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: rolling upgrades
> Reporter: Kihwal Lee
> Assignee: Kihwal Lee
> Priority: Critical
> Attachments: HDFS-7603.patch
>
>
> The background replication queue initialization processes configured number
> of blocks at a time and releases the namesystem write lock. This was to let
> namenode start serving right after a standby to active transition or leaving
> safe mode. However, this does not allow others to run much if the lock
> fairness is set to "unfair" for the higher throughput.
> I propose adding a delay between unlocking and locking in the async repl
> queue init thread.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
