[jira] [Created] (HADOOP-12677) DecompressorStream throws IndexOutOfBoundsException when calling skip(long)
Laurent Goujon created HADOOP-12677: --- Summary: DecompressorStream throws IndexOutOfBoundsException when calling skip(long) Key: HADOOP-12677 URL: https://issues.apache.org/jira/browse/HADOOP-12677 Project: Hadoop Common Issue Type: Bug Reporter: Laurent Goujon DecompressorStream.skip(long) throws an IndexOutOfBoundException when using a long bigger than Integer.MAX_VALUE This is because of this cast from long to int: https://github.com/apache/hadoop-common/blob/HADOOP-3628/src/core/org/apache/hadoop/io/compress/DecompressorStream.java#L125 The fix is probably to do the cast after applying Math.min: in that case, it should not be an issue since it should not be bigger than the buffer size (512) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HADOOP-12126) Configuration might use ApplicationClassLoader to create XML parser
Laurent Goujon created HADOOP-12126:
---
Summary: Configuration might use ApplicationClassLoader to create
XML parser
Key: HADOOP-12126
URL: https://issues.apache.org/jira/browse/HADOOP-12126
Project: Hadoop Common
Issue Type: Bug
Components: conf
Reporter: Laurent Goujon
{{org.apache.hadoop.conf.Configuration}} creates a new DocumentBuilder to parse
the XML config files, but it doesn't specify which classloader to use to
discover and instantiate the XML parser.
Because DocumentBuilderFactory relies on ServiceProvider, whose by default,
uses the context classloader. If classpath isolation is turned on, one might
expect that that Configuration will only load classes from the system
classloader, but it turns out that the context classloader is set to
ApplicationClassLoader, and that a XML parser might be loaded from the user
classpath.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (HADOOP-10297) FileChecksum should provide getChecksumOpt method
Laurent Goujon created HADOOP-10297: --- Summary: FileChecksum should provide getChecksumOpt method Key: HADOOP-10297 URL: https://issues.apache.org/jira/browse/HADOOP-10297 Project: Hadoop Common Issue Type: Improvement Reporter: Laurent Goujon o.a.h.f.FileSystem has several methods which accepts directly or indirectly a ChecksumOpt parameter to configure checksum options, but there's no generic way of querying checksum options used for a given file. MD5MD5CRC32FileChecksum used by DFSClient has a getChecksumOpt() but since not just DistributedFileSystem is accepting a ChecksumOpt argument, but any FileSystem subclass (although only DistributedFileSystem implements a specific behaviour), I suggest to make getChecksumOpt an abstract method of FileChecksum. This could be used by tools like DistCp to replicate checksum options for example. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (HADOOP-10289) o.a.h.u.ReflectionUtils.printThreadInfo() causes deadlock in TestHttpServer
Laurent Goujon created HADOOP-10289: --- Summary: o.a.h.u.ReflectionUtils.printThreadInfo() causes deadlock in TestHttpServer Key: HADOOP-10289 URL: https://issues.apache.org/jira/browse/HADOOP-10289 Project: Hadoop Common Issue Type: Bug Components: util Affects Versions: 3.0.0, 2.4.0 Environment: MacOS X 10.9/Java 6 1.6.0_65-b14-462 Reporter: Laurent Goujon This bug is a followup on HADOOP-9964 ReflectionUtils.printThreadInfo is now a synchronized method. This change creates sometimes deadlock situation in TestHttpServer if one servlet thread calling this method is waiting on client to consume output. In TestHttpServer, several tests connect to the http server only to check the status code but without reading the full inputstream. Depending on HttpURLConnection, the deadlock scenario may be triggered or not. Note that in the original ticket, it is not explained why synchronized fixed the issue. According to the attached stacktrace, test was blocked on HttpServer.stop(), waiting on worker threads to stop, which didn't happen because those threads were waiting for their output to be consumed, so the original issue looks very similar to what I'm experiencing. My proposed fix is to remove synchronized (as it seems to make the issue worse) but configure HttpServer.stop() to forcibly kill threads after a configurable period of time -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (HADOOP-10290) Surefire steals focus on MacOS
Laurent Goujon created HADOOP-10290:
---
Summary: Surefire steals focus on MacOS
Key: HADOOP-10290
URL: https://issues.apache.org/jira/browse/HADOOP-10290
Project: Hadoop Common
Issue Type: Bug
Components: build
Reporter: Laurent Goujon
When running tests on MacOS X, surefire plugin keeps stealing focus from
current application.
This can be avoided by adding {noformat}-Djava.awt.headless=true{noformat} to
the surefire commandline
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Created] (HADOOP-10287) FSOutputSummer should support any checksum size
Laurent Goujon created HADOOP-10287: --- Summary: FSOutputSummer should support any checksum size Key: HADOOP-10287 URL: https://issues.apache.org/jira/browse/HADOOP-10287 Project: Hadoop Common Issue Type: Bug Components: fs Affects Versions: 2.2.0, 3.0.0 Reporter: Laurent Goujon HADOOP-9114 only fixes if checksum size is 0, but doesn't handle the generic case. FSOutputSummer should work with any checksum size (between 0 and 8 since Checksum.getValue() returns a long) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
