[docs] update on automatic authn token reacquisition

Updated corresponding section in the docs about the automatic authentication token reacquisition in the Java client. This is a follow-up for 603c157 Change-Id: Ide2da98e6a9b1176da2ce4d8157c4b11850e6c1f Reviewed-on: http://gerrit.cloudera.org:8080/7837 Tested-by: Alexey Serbin <[email protected]> Reviewed-by: Todd Lipcon <[email protected]>
timarmstrong · Aug 25, 2017 · 64c0b15 · 64c0b15
1 parent ddb95e5
commit 64c0b15
Show file tree

Hide file tree

Showing 2 changed files with 0 additions and 10 deletions.
diff --git a/docs/known_issues.adoc b/docs/known_issues.adoc
@@ -167,10 +167,6 @@
 * Kudu's integration with Apache Flume does not support writing to Kudu clusters that
   require Kerberos authentication.
 
-* Kudu client instances retrieve authentication tokens upon first contact with the
-  cluster. These tokens expire after one week. Use of a single Kudu client instance
-  for more than one week is only supported by the C++ client but not by the Java client.
-
 == Other Known Issues
 
 The following are known bugs and issues with the current release of Kudu. They will

diff --git a/docs/security.adoc b/docs/security.adoc
@@ -229,12 +229,6 @@ Kudu has a few known security limitations:
 
 // TODO(danburkert): add JIRA links for each of these.
 
-Long-lived Tokens:: The Java Kudu client does not automatically request fresh
-authn tokens after initial token expiration, so long-lived Java clients in
-secure clusters are not supported. However, the C++ Kudu client does
-automatically request fresh authn tokens, so long-lived C++ clients
-(i.e. beyond authn token lifetime) in secure clusters are supported.
-
 Custom Kerberos Principal:: Kudu does not support setting a custom service
 principal for Kudu processes. The principal must be 'kudu'.