[jira] [Created] (HDFS-4345) Release resources of unpoolable Decompressors

Lars Hofhansl created HDFS-4345: --- Summary: Release resources of unpoolable Decompressors Key: HDFS-4345 URL: https://issues.apache.org/jira/browse/HDFS-4345 Project: Hadoop HDFS Issue Type: Bug

[jira] [Created] (HDFS-4344) dfshealth.jsp throws NumberFormatException when dfs.hosts/dfs.hosts.exclude includes port number

tamtam180 created HDFS-4344: --- Summary: dfshealth.jsp throws NumberFormatException when dfs.hosts/dfs.hosts.exclude includes port number Key: HDFS-4344 URL: https://issues.apache.org/jira/browse/HDFS-4344 Pr

[jira] [Created] (HDFS-4343) When storageID of dfs.data.dir of being inconsistent, restart datanode will be failure.

liuyang created HDFS-4343: - Summary: When storageID of dfs.data.dir of being inconsistent, restart datanode will be failure. Key: HDFS-4343 URL: https://issues.apache.org/jira/browse/HDFS-4343 Project: Hadoop

[jira] [Created] (HDFS-4342) Edits dir in dfs.namenode.edits.dir.required will be silently ignored if it is not in dfs.namenode.edits.dir

Mark Yang created HDFS-4342: --- Summary: Edits dir in dfs.namenode.edits.dir.required will be silently ignored if it is not in dfs.namenode.edits.dir Key: HDFS-4342 URL: https://issues.apache.org/jira/browse/HDFS-4342

Re: Release of Decompressor resources in CodecPool

I think that you're right. It looks like BuiltInGzipDecompressor, which is marked as DoNotPool, ends up owning some JNI-managed resources. In this case, just relying on the GC to get around to calling the finalizer isn't a great idea. I think you should open a JIRA. cheers, Colin On Mon, Dec

Re: Recovering fsImage from Namenode Logs

On Thu, Dec 20, 2012 at 12:33 AM, ishan chhabra wrote: > Unfortunately, the checkpoint image that I have has the deletes recorded. I > cannot use it. I do have an image that is 15 days old, which I am currently > running. > > I looked at the my logs and I have the filename, block allocated and > g

Re: FSDataInputStream.read returns -1 with growing file and never continues reading

Also, read() returning -1 is not an error, it's EOF. This is the same as for the regular Java InputStream. best, Colin On Thu, Dec 20, 2012 at 10:32 AM, Christoph Rupp wrote: > Thank you, Harsh. I appreciate it. > > 2012/12/20 Harsh J > >> Hi Christoph, >> >> If you use sync/hflush/hsync, the

[jira] [Created] (HDFS-4340) Update addBlock() to inculde inode id as additional argument

Brandon Li created HDFS-4340: Summary: Update addBlock() to inculde inode id as additional argument Key: HDFS-4340 URL: https://issues.apache.org/jira/browse/HDFS-4340 Project: Hadoop HDFS Issue

[jira] [Created] (HDFS-4339) Persist inode id in fsimage and editlog

Brandon Li created HDFS-4339: Summary: Persist inode id in fsimage and editlog Key: HDFS-4339 URL: https://issues.apache.org/jira/browse/HDFS-4339 Project: Hadoop HDFS Issue Type: Sub-task

[jira] [Created] (HDFS-4338) TestNameNodeMetrics#testCorruptBlock is flaky

Andrew Wang created HDFS-4338: - Summary: TestNameNodeMetrics#testCorruptBlock is flaky Key: HDFS-4338 URL: https://issues.apache.org/jira/browse/HDFS-4338 Project: Hadoop HDFS Issue Type: Bug

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

See https://builds.apache.org/job/Hadoop-Hdfs-trunk/1267/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 9835 lines...] Running org.apache.hadoop.hdfs.web.resourc

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

See Changes: [jlowe] MAPREDUCE-4902. Fix typo "receievd" should be "received" in log output. Contributed by Albert Chu -- [...truncated 9642 lines...] Running org.apache.hadoop.hdfs.server.nam

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

See

Hadoop-Hdfs-0.23-Build - Build # 476 - Unstable

See https://builds.apache.org/job/Hadoop-Hdfs-0.23-Build/476/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 12334 lines...] [INFO] [INFO] --- maven-dependency-p