[
https://issues.apache.org/jira/browse/HDFS-14135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16717718#comment-16717718
]
Ayush Saxena commented on HDFS-14135:
-------------------------------------
Checked the following link.
[https://stackoverflow.com/questions/5111040/listen-ignores-the-backlog-argument]
Guess the Backlog setting is quite random and isn't specifically defined.
Even in the code.It is mentioned as.
{code:java}
The method saves a reference to each
* new SocketChannel so that it can be closed during tearDown. We define a
* very small connection backlog, but the OS may silently enforce a larger
* minimum backlog than requested. To work around this, we create far more
* client connections than our defined backlog.
{code}
Not sure what exactly this larger value is at the backend and how large it is?
Does it change?
Should we try with a very large number? or make it a blocking thread and use
some sort of principals like Future Executor and thread concepts to run until
the connection gets block and then check out use?
Any Suggestions??
> TestWebHdfsTimeouts Fails intermittently in trunk
> -------------------------------------------------
>
> Key: HDFS-14135
> URL: https://issues.apache.org/jira/browse/HDFS-14135
> Project: Hadoop HDFS
> Issue Type: Bug
> Reporter: Ayush Saxena
> Assignee: Ayush Saxena
> Priority: Major
> Attachments: HDFS-14135-01.patch, HDFS-14135-02.patch,
> HDFS-14135-03.patch, HDFS-14135-04.patch, HDFS-14135-05.patch
>
>
> Reference to failure
> https://builds.apache.org/job/hadoop-qbt-trunk-java8-linux-x86/982/testReport/junit/org.apache.hadoop.hdfs.web/TestWebHdfsTimeouts/
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
