Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id F024B200C79 for ; Fri, 19 May 2017 22:56:07 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id ECDFC160BD2; Fri, 19 May 2017 20:56:07 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 400D5160BB0 for ; Fri, 19 May 2017 22:56:07 +0200 (CEST) Received: (qmail 67694 invoked by uid 500); 19 May 2017 20:56:06 -0000 Mailing-List: contact common-issues-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list common-issues@hadoop.apache.org Received: (qmail 67683 invoked by uid 99); 19 May 2017 20:56:06 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 19 May 2017 20:56:06 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id CACA5180158 for ; Fri, 19 May 2017 20:56:05 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -99.202 X-Spam-Level: X-Spam-Status: No, score=-99.202 tagged_above=-999 required=6.31 tests=[KAM_ASCII_DIVIDERS=0.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=disabled Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id vTn1w2c2_YgO for ; Fri, 19 May 2017 20:56:05 +0000 (UTC) Received: from mailrelay1-us-west.apache.org (mailrelay1-us-west.apache.org [209.188.14.139]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTP id C94005FC64 for ; Fri, 19 May 2017 20:56:04 +0000 (UTC) Received: from jira-lw-us.apache.org (unknown [207.244.88.139]) by mailrelay1-us-west.apache.org (ASF Mail Server at mailrelay1-us-west.apache.org) with ESMTP id 61D67E02C8 for ; Fri, 19 May 2017 20:56:04 +0000 (UTC) Received: from jira-lw-us.apache.org (localhost [127.0.0.1]) by jira-lw-us.apache.org (ASF Mail Server at jira-lw-us.apache.org) with ESMTP id 0F41521B56 for ; Fri, 19 May 2017 20:56:04 +0000 (UTC) Date: Fri, 19 May 2017 20:56:04 +0000 (UTC) From: "Yongjun Zhang (JIRA)" To: common-issues@hadoop.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (HADOOP-14441) LoadBalancingKMSClientProvider#addDelegationTokens should add delegation tokens from all KMS instances MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 archived-at: Fri, 19 May 2017 20:56:08 -0000 [ https://issues.apache.org/jira/browse/HADOOP-14441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16017994#comment-16017994 ] Yongjun Zhang commented on HADOOP-14441: ---------------------------------------- But I don't see the catch/retry in Hadoop code. Do we expect client code to do so? It seems we should do it within Hadoop. [~jojochuang]. > LoadBalancingKMSClientProvider#addDelegationTokens should add delegation tokens from all KMS instances > ------------------------------------------------------------------------------------------------------ > > Key: HADOOP-14441 > URL: https://issues.apache.org/jira/browse/HADOOP-14441 > Project: Hadoop Common > Issue Type: Bug > Components: kms > Affects Versions: 2.7.0 > Environment: CDH5.7.4, Kerberized, SSL, KMS-HA, at rest encryption > Reporter: Wei-Chiu Chuang > Assignee: Wei-Chiu Chuang > Attachments: HADOOP-14441.001.patch, HADOOP-14441.002.patch > > > LoadBalancingKMSClientProvider only gets delegation token from one KMS instance, in a round-robin fashion. This is arguably a bug, as JavaDoc for {{KeyProviderDelegationTokenExtension#addDelegationTokens}} states: > {quote} > /** > * The implementer of this class will take a renewer and add all > * delegation tokens associated with the renewer to the > * Credentials object if it is not already present, > ... > **/ > {quote} > This bug doesn't pop up very often, because HDFS clients such as MapReduce unintentionally calls {{FileSystem#addDelegationTokens}} multiple times. > We have a custom client that accesses HDFS/KMS-HA using delegation token, and we were puzzled why it always throws "Failed to find any Kerberos tgt" exceptions talking to one KMS but not the other. Turns out that client couldn't talk to the KMS because {{FileSystem#addDelegationTokens}} only gets one KMS delegation token at a time. -- This message was sent by Atlassian JIRA (v6.3.15#6346) --------------------------------------------------------------------- To unsubscribe, e-mail: common-issues-unsubscribe@hadoop.apache.org For additional commands, e-mail: common-issues-help@hadoop.apache.org