[
https://issues.apache.org/jira/browse/HADOOP-10289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14120480#comment-14120480
]
Hadoop QA commented on HADOOP-10289:
------------------------------------
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12625220/hadoop-10289.patch
against trunk revision 1dcaba9.
{color:red}-1 patch{color}. The patch command could not apply the patch.
Console output:
https://builds.apache.org/job/PreCommit-HADOOP-Build/4639//console
This message is automatically generated.
> 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.3.0
> Environment: MacOS X 10.9/Java 6 1.6.0_65-b14-462
> Reporter: Laurent Goujon
> Attachments: TestHttpServer.jstack, hadoop-10289.patch
>
>
> 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.3.4#6332)
