[
https://issues.apache.org/jira/browse/HIVE-15184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15945661#comment-15945661
]
Sunitha Beeram commented on HIVE-15184:
---------------------------------------
[~pvary], could you explain why we are calling runtime.exit() in case of
unrecoverable error? It seems like we are saying that the metastore should not
work anymore if we are not able to cleanup expired tokens. Seems a little
extreme to me.
You mentioned that you tested this with shutting the db down, what would happen
if it was a transient connection exception? In our environment, we are seeing
this:
{noformat}
2017-03-28 17:03:26,192 ERROR thrift.TokenStoreDelegationTokenSecretManager
(TokenStoreDelegationTokenSecretManager.java:run(331)) - ExpiredTokenRemover
thread received unexpected exception. org.apache.hadoop.hive.thrift
.DelegationTokenStore$TokenStoreException: javax.jdo.JDODataStoreException:
Communications link failure
{noformat}
It appears that the above is triggered when we somehow end up reusing a "dead"
connection (we are still investigating this). Anyway, just wanted to mention
that it might be better to reconsider the exit() option.
> Add the possibility to separate recoverable and not recoverable errors in
> DeletagionTokenStore
> ----------------------------------------------------------------------------------------------
>
> Key: HIVE-15184
> URL: https://issues.apache.org/jira/browse/HIVE-15184
> Project: Hive
> Issue Type: Bug
> Components: HiveServer2, Metastore
> Affects Versions: 1.3.0, 2.1.0, 2.0.1, 2.2.0
> Reporter: Peter Vary
> Assignee: Peter Vary
> Attachments: HIVE-15184.patch
>
>
> After HIVE-15090 committed we discussed it with [~thejas] and agreed, that it
> would be even better if the DelegateTokenStore implementation could decide if
> an error is recoverable or not. Since the DelegationTokenStore is not
> mentioned as a Hive API it is possible to change the interface, so we could
> change the implementations shipped with Hive to use the new functionality,
> and if someone uses it's own implementation of DelegationTokenStore, then he
> should do the matching changes himself
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
