[ 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