[
https://issues.apache.org/jira/browse/HIVE-20173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16564061#comment-16564061
]
Aaron Gottlieb commented on HIVE-20173:
---------------------------------------
I do not think it is warranted either. So I believe my options are to either
# allow the JDOException to escape or
# add MetaException to the list of thrown exceptions of
org.apache.hadoop.hive.metastore.RawStore#getDatabase and alter
org.apache.hadoop.hive.metastore.ObjectStore#getDatabase to not wrap the
MetaException
I suppose no existing code could break for option 2 as its _adding_ an
exception. Looking at the interface of RawStore, almost every other method
does specify MetaException, making the lack of it on getDatabase seem like an
oversight. Does anyone know any history of why its missing on getDatabase?
Should it have been there the whole time?
If there's no reason not to include it, I'll submit a patch with this change.
> MetaStoreDirectSql#executeWithArray should not catch RuntimeExceptions from
> JDO
> -------------------------------------------------------------------------------
>
> Key: HIVE-20173
> URL: https://issues.apache.org/jira/browse/HIVE-20173
> Project: Hive
> Issue Type: Bug
> Components: Metastore
> Affects Versions: 1.1.0
> Reporter: Aaron Gottlieb
> Priority: Major
>
> When attempting to test the existence of a Hive database, the Metastore will
> query the backing database.
> The method MetaStoreDirectSql#executeWithArray catches all exceptions,
> turning them into MetaExceptions.
> Further up the stack, the ObjectStore#getDatabase explicitly catches
> MetaExceptions and turns them into NoSuchObjectExceptions.
> Finally, RetryingHMSHandler explicitly looks for NoSuchObjectExceptions and
> does _not_ retry them, thinking they are legitimate answers.
> If the exception in MetaStoreDirectSql#executeWithArray was a runtime
> JDOException due to, say, some sort of network error between the Metastore
> and the backing database, this inability to query the backing database looks
> just like an answer of "no database exists" higher up the stack. Any program
> depending on this information will continue with an incorrect answer rather
> than retrying the original getDatabase query.
> I am unsure the extent of the effects of this, but I imagine that explicitly
> _not_ catching RuntimeExceptions in MetaStoreDirectSql#executeWithArray will
> allow the exception to raise all the way up to the RetryingHMSHandler which
> will, correctly, retry the operation.
> Would allowing RuntimeExceptions to be thrown from
> MetaStoreDirectSql#executeWithArray be too deleterious? Or did I miss some
> code path such that my observations are incorrect?
>
> Thanks,
> Aaron
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
