[
https://issues.apache.org/jira/browse/HADOOP-10289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15282044#comment-15282044
]
Hadoop QA commented on HADOOP-10289:
------------------------------------
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 0s
{color} | {color:blue} Docker mode activated. {color} |
| {color:red}-1{color} | {color:red} patch {color} | {color:red} 0m 4s {color}
| {color:red} HADOOP-10289 does not apply to trunk. Rebase required? Wrong
Branch? See https://wiki.apache.org/hadoop/HowToContribute for help. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12625220/hadoop-10289.patch |
| JIRA Issue | HADOOP-10289 |
| Console output |
https://builds.apache.org/job/PreCommit-HADOOP-Build/9387/console |
| Powered by | Apache Yetus 0.3.0-SNAPSHOT http://yetus.apache.org |
This message was 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: 2.3.0, 3.0.0-alpha1
> 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)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
