hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gregory Chanan (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HADOOP-11157) ZKDelegationTokenSecretManager never shuts down listenerThreadPool
Date Fri, 31 Oct 2014 01:14:33 GMT

    [ https://issues.apache.org/jira/browse/HADOOP-11157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14191152#comment-14191152

Gregory Chanan commented on HADOOP-11157:

Some notes:
private void processTokenAddOrUpdate(ChildData data) throws IOException {
    Stat stat = null;
    try {
      stat = zkClient.checkExists().forPath(data.getPath());
    } catch (Exception e) {
      LOG.warn("Could not get path for Token Add/Update notification.. going to update !!",
      stat = null;
I don't think setting stat to null is necessary and I don't understand the warning -- aren't
you not going to do anything in the rest of the function because stat is null anyway?

+      stat = zkClient.checkExists().forPath(data.getPath());
+    } catch (Exception e) {
+      LOG.warn("Could not get path for Token Delete notification.. going to delete from localcache
!!", e);
+      stat = null;
+    }
Again, setting stat to null doesn't seem necessary.

+    // Check if Token has already been cancelled..
+    if (stat == null) {
Here, and in the opposite case where stat == null on the add/remove, don't we want to handle
those cases?  We aren't guaranteed to see every notification (http://zookeeper.apache.org/doc/trunk/zookeeperProgrammers.html#ch_zkWatches).
 Should we just have one handle function where you run the logic based on the current state?

- It would be nice if there were a test for starting a secret manager after a delegation token
on another secret manager has already been created, and verifying it works.  Also, the same
case but shutting down and restarting a secret manager and verifying the tokens (for itself
or for others still works).

> ZKDelegationTokenSecretManager never shuts down listenerThreadPool
> ------------------------------------------------------------------
>                 Key: HADOOP-11157
>                 URL: https://issues.apache.org/jira/browse/HADOOP-11157
>             Project: Hadoop Common
>          Issue Type: Bug
>          Components: security
>    Affects Versions: 2.6.0
>            Reporter: Gregory Chanan
>            Assignee: Arun Suresh
>         Attachments: HADOOP-11157.2.patch, HADOOP-11157.patch, HADOOP-11157.patch
> I'm trying to integrate Solr with the DelegationTokenAuthenticationFilter and running
into this issue.  The solr unit tests look for leaked threads and when I started using the
ZKDelegationTokenSecretManager it started reporting leaks.  Shuting down the listenerThreadPool
after the objects that use it resolves the leak threads errors.

This message was sent by Atlassian JIRA

View raw message