[
https://issues.apache.org/jira/browse/HADOOP-11684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14727276#comment-14727276
]
Thomas Demoor commented on HADOOP-11684:
----------------------------------------
Thanks for the review Aaron.
I did. I think that with CallerRunsPolicy, if multiple write commands would be
issued from separate threads, each of these threads would be allowed to
continue, still running the JVM into an OOM. I agree this is quite far fetched,
but, as there is a whole ecosystem depending on the Hadoop filesystems, I went
for the robuster (but indeed more complex and thus error-prone) implementation.
If people who know the ecosystem better than me can assert that this case does
not occur "in the wild" I'm fine with simply using CallerRunsPolicy.
> S3a to use thread pool that blocks clients
> ------------------------------------------
>
> Key: HADOOP-11684
> URL: https://issues.apache.org/jira/browse/HADOOP-11684
> Project: Hadoop Common
> Issue Type: Sub-task
> Components: fs/s3
> Affects Versions: 2.7.0
> Reporter: Thomas Demoor
> Assignee: Thomas Demoor
> Attachments: HADOOP-11684-001.patch, HADOOP-11684-002.patch
>
>
> Currently, if fs.s3a.max.total.tasks are queued and another (part)upload
> wants to start, a RejectedExecutionException is thrown.
> We should use a threadpool that blocks clients, nicely throtthling them,
> rather than throwing an exception. F.i. something similar to
> https://github.com/apache/incubator-s4/blob/master/subprojects/s4-comm/src/main/java/org/apache/s4/comm/staging/BlockingThreadPoolExecutorService.java
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
