[
https://issues.apache.org/jira/browse/HADOOP-13105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15283007#comment-15283007
]
Chris Nauroth commented on HADOOP-13105:
----------------------------------------
[~liuml07], thank you for the patch.
# I agree with handling both connection timeout and read timeout within the
scope of this patch.
# I agree with the suggestion to make the timeout settings configurable, and
use something pretty long, like 60 seconds, as the default. A value of "0"
could mean "don't set the timeout". That way, there is minimal impact to
existing LDAP deployments that experience long latency, and in case anyone
really wants the old unbounded wait behavior, they can set it to 0.
# For testing, I suggest looking at {{TestWebHdfsTimeouts}}, which uses
techniques similar to what your test here does. To cover read timeout, it
starts a TCP server that accepts connections but never responds, like what your
patch already does. To simulate connect timeout, it spams a bunch of
connections at that server to consume the TCP connection backlog before running
the test.
bq. Out of curiosity, doesn't the property
{{hadoop.security.group.mapping.ldap.directory.search.timeout}} work for this
purpose?
[~jojochuang], I'm pretty sure this is something different. This is an
application layer control, passed in the LDAP query, to give the LDAP server a
hint that it should expect the query to complete in this amount of time. An
LDAP server may choose to abort its query if it cannot complete within this
timeout. This does not control timeouts at the TCP layer. It would not catch
connection timeouts due to an overloaded LDAP server that has exhausted its
listen backlog. It also would not catch timeouts if the LDAP server
implementation chooses not to respect the search timeout. It also wouldn't
cover cases like firewall misconfigurations that accept the client's SYN packet
for connection establishment, but then drop subsequent packets.
At least that's my recollection of what the search timeout does.
Unfortunately, I can't find a definitive reference for that on the web right
now to backup my claim. :-) I definitely have seen LDAP connection timeouts
and read timeouts despite having the search timeout configured correctly.
If you were thinking of overloading
{{hadoop.security.group.mapping.ldap.directory.search.timeout}} to also pass
that same value for these new connect and read timeout settings, I'd instead
prefer new properties for greater flexibility.
> Support timeouts in LDAP queries in LdapGroupsMapping.
> ------------------------------------------------------
>
> Key: HADOOP-13105
> URL: https://issues.apache.org/jira/browse/HADOOP-13105
> Project: Hadoop Common
> Issue Type: Improvement
> Components: security
> Reporter: Chris Nauroth
> Assignee: Mingliang Liu
> Attachments: HADOOP-13105.000.patch
>
>
> {{LdapGroupsMapping}} currently does not set timeouts on the LDAP queries.
> This can create a risk of a very long/infinite wait on a connection.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org
