Mailing-List: contact common-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: common-issues@hadoop.apache.org
Date: Tue, 21 Feb 2012 15:18:38 +0000 (UTC)
From: "Kihwal Lee (Updated) (JIRA)" <jira@apache.org>
To: common-issues@hadoop.apache.org
Message-ID: 
 <1718539988.6059.1329837518058.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1926821649.52360.1329516777507.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Updated] (HADOOP-8088) User-group mapping cache incorrectly
 does negative caching on transient failures
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


     [ https://issues.apache.org/jira/browse/HADOOP-8088?page=3Dcom.atlassi=
an.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kihwal Lee updated HADOOP-8088:
-------------------------------

    Description: We've seen a case where some getGroups() calls fail when t=
he ldap server or the network is having transient failures. Looking at the =
code, the shell-based and the JNI-based implementations swallow exceptions =
and return an empty or partial list. The caller, Groups#getGroups() adds th=
is likely empty list into the mapping cache for the user. This will functio=
n as negative caching until the cache expires. I don't think we want negati=
ve caching here, but even if we do, it should be intelligent enough to dist=
inguish transient failures from ENOENT. The log message in the jni-based im=
pl also needs an improvement. It should print what exception it encountered=
 instead of just saying one happened.  (was: We've seen a case where some g=
etGroups() calls fail when the ldap server or the network has a transient i=
ssue. Looking the code, the shell-based and the JNI-based implementation sw=
allow exceptions and return an empty or partial list. The caller, Groups#ge=
tGroups() adds this likely empty list into the mapping cache for the user. =
This will function as negative caching until the cache expires. I don't thi=
nk we want negative caching here, but even if we do, it should be intellige=
nt enough to distinguish transient failures from ENOENT. The log message in=
 the jni-based impl also needs an improvement. It should print what excepti=
on it encountered instead of just saying one happened.)
   =20
> User-group mapping cache incorrectly does negative caching on transient f=
ailures
> -------------------------------------------------------------------------=
-------
>
>                 Key: HADOOP-8088
>                 URL: https://issues.apache.org/jira/browse/HADOOP-8088
>             Project: Hadoop Common
>          Issue Type: Bug
>          Components: security
>    Affects Versions: 0.20.205.0, 0.24.0, 0.23.1, 1.0.0, 1.1.0
>            Reporter: Kihwal Lee
>             Fix For: 0.24.0, 1.1.0, 0.23.2
>
>
> We've seen a case where some getGroups() calls fail when the ldap server =
or the network is having transient failures. Looking at the code, the shell=
-based and the JNI-based implementations swallow exceptions and return an e=
mpty or partial list. The caller, Groups#getGroups() adds this likely empty=
 list into the mapping cache for the user. This will function as negative c=
aching until the cache expires. I don't think we want negative caching here=
, but even if we do, it should be intelligent enough to distinguish transie=
nt failures from ENOENT. The log message in the jni-based impl also needs a=
n improvement. It should print what exception it encountered instead of jus=
t saying one happened.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrato=
rs: https://issues.apache.org/jira/secure/ContactAdministrators!default.jsp=
a
For more information on JIRA, see: http://www.atlassian.com/software/jira