hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Nauroth (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HADOOP-13105) Support timeouts in LDAP queries in LdapGroupsMapping.
Date Fri, 13 May 2016 18:55:12 GMT

    [ 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
# 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

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

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

To unsubscribe, e-mail: common-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-issues-help@hadoop.apache.org

View raw message