avro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hudson (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (AVRO-1144) Deadlock with FSInput and Hadoop NativeS3FileSystem.
Date Wed, 31 Jul 2013 03:37:50 GMT

    [ https://issues.apache.org/jira/browse/AVRO-1144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13724816#comment-13724816

Hudson commented on AVRO-1144:

SUCCESS: Integrated in AvroJava #387 (See [https://builds.apache.org/job/AvroJava/387/])
AVRO-1144 Deadlock with FSInput and Hadoop NativeS3FileSystem (scottcarey: rev 1508713)
* /avro/trunk/CHANGES.txt
* /avro/trunk/lang/java/mapred/src/main/java/org/apache/avro/mapred/FsInput.java

> Deadlock with FSInput and Hadoop NativeS3FileSystem.
> ----------------------------------------------------
>                 Key: AVRO-1144
>                 URL: https://issues.apache.org/jira/browse/AVRO-1144
>             Project: Avro
>          Issue Type: Bug
>          Components: java
>    Affects Versions: 1.7.0
>         Environment: Hadoop 1.0.3
>            Reporter: Shawn Smith
>            Assignee: Scott Carey
>             Fix For: 1.7.5
>         Attachments: AVRO-1144.patch
> Deadlock can occur when using org.apache.avro.mapred.FsInput to read files from S3 using
the Hadoop NativeS3FileSystem and multiple threads.
> There are a lot of components involved, but the basic cause is pretty simple: Apache
Commons HttpClient can deadlock waiting for a free HTTP connection when the number of threads
downloading from S3 is greater than or equal to the maximum allowed HTTP connections per host.
> I've filed this bug against Avro because the bug is easiest to fix in Avro.  Swap the
order of the FileSystem.open() and FileSystem.getFileStatus() calls in the FSInput constructor:
> {noformat}
> /** Construct given a path and a configuration. */
> public FsInput(Path path, Configuration conf) throws IOException {
>   this.stream = path.getFileSystem(conf).open(path);
>   this.len = path.getFileSystem(conf).getFileStatus(path).getLen();
> }
> {noformat}
> to
> {noformat}
> /** Construct given a path and a configuration. */
> public FsInput(Path path, Configuration conf) throws IOException {
>   this.len = path.getFileSystem(conf).getFileStatus(path).getLen();
>   this.stream = path.getFileSystem(conf).open(path);
> }
> {noformat}
> Here's what triggers the deadlock:
> * FSInput calls FileSystem.open() which calls Jets3t to connect to S3 and open an HTTP
connection for downloading content.  This acquires an HTTP connection but does not release
> * FSInput calls FileSystem.getFileStatus() which calls Jets3t to connect to S3 and perform
a HEAD request to get object metadata.  This attempts to acquire a second HTTP connection.
> * Jets3t uses Apache Commons HTTP Client which limits the number of simultaneous HTTP
connections to a given host.  Lets say this maximum is 4 (the default)...  If 4 threads all
call the FSInput constructor concurrently, the 4 FileSystem.open() calls can acquire all 4
available connections and the FileSystem.getFileStatus() calls block forever waiting for a
thread to release an HTTP connection back to the connection pool.
> A simple way to reproduce the problem this problem is to create "jets3t.properties" in
your classpath with "httpclient.max-connections=1".  Then try to open a file using FSInput
and the Native S3 file system (new Path("s3n://<bucket>/<path>")).  It will hang
indefinitely inside the FSInput constructor.
> Swapping the order of the open() and getFileStatus() calls ensures that a given thread
using FSInput has at most one outstanding connection S3 at a time.  As a result, one thread
should always be able to make progress, avoiding deadlock.
> Here's a sample stack trace of a deadlocked thread:
> {noformat}
> "pool-10-thread-3" prio=5 tid=11026f800 nid=0x116a04000 in Object.wait() [116a02000]
>    java.lang.Thread.State: WAITING (on object monitor)
> 	at java.lang.Object.wait(Native Method)
> 	- waiting on <785892cc0> (a org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$ConnectionPool)
> 	at org.apache.commons.httpclient.MultiThreadedHttpConnectionManager.doGetConnection(MultiThreadedHttpConnectionManager.java:518)
> 	- locked <785892cc0> (a org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$ConnectionPool)
> 	at org.apache.commons.httpclient.MultiThreadedHttpConnectionManager.getConnectionWithTimeout(MultiThreadedHttpConnectionManager.java:416)
> 	at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:153)
> 	at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397)
> 	at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:323)
> 	at org.jets3t.service.impl.rest.httpclient.RestS3Service.performRequest(RestS3Service.java:357)
> 	at org.jets3t.service.impl.rest.httpclient.RestS3Service.performRestHead(RestS3Service.java:652)
> 	at org.jets3t.service.impl.rest.httpclient.RestS3Service.getObjectImpl(RestS3Service.java:1556)
> 	at org.jets3t.service.impl.rest.httpclient.RestS3Service.getObjectDetailsImpl(RestS3Service.java:1492)
> 	at org.jets3t.service.S3Service.getObjectDetails(S3Service.java:1793)
> 	at org.jets3t.service.S3Service.getObjectDetails(S3Service.java:1225)
> 	at org.apache.hadoop.fs.s3native.Jets3tNativeFileSystemStore.retrieveMetadata(Jets3tNativeFileSystemStore.java:111)
> 	at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.apache.hadoop.io.retry.RetryInvocationHandler.invokeMethod(RetryInvocationHandler.java:82)
> 	at org.apache.hadoop.io.retry.RetryInvocationHandler.invoke(RetryInvocationHandler.java:59)
> 	at org.apache.hadoop.fs.s3native.$Proxy25.retrieveMetadata(Unknown Source)
> 	at org.apache.hadoop.fs.s3native.NativeS3FileSystem.getFileStatus(NativeS3FileSystem.java:326)
> 	at org.apache.avro.mapred.FsInput.<init>(FsInput.java:38)
> 	at org.apache.crunch.io.avro.AvroFileReaderFactory.read(AvroFileReaderFactory.java:70)
> 	at org.apache.crunch.io.CompositePathIterable$2.<init>(CompositePathIterable.java:80)
> 	at org.apache.crunch.io.CompositePathIterable.iterator(CompositePathIterable.java:78)
> 	at com.example.load.BulkLoader$1.run(BulkLoadCommand.java:109)
> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:680)
> {noformat}

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

View raw message