[
https://issues.apache.org/jira/browse/HIVE-18349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16317173#comment-16317173
]
Prasanth Jayachandran commented on HIVE-18349:
----------------------------------------------
bq. Why should this method be throwing if the context says failure?
Context is available only through listeners. There is no way to know the final
state when using the API directly without registering any listeners.
The commit transaction returns a boolean which is not handled by any of the
metastore functions.If the commit transaction fails for some reason on the db
side, we rollback the transaction but API will silently ignore the failure. The
only way to know if a metastore api succeeded is to look for the state in the
context which is only available if listeners are registered. In one of the
customer case, we saw a case where drop_table API completed successfully
although the commit transaction failed in postgres (transaction rolled back but
not indication via API). To detect such cases, the exception is thrown in the
endFunction when state is failure and no exception is observed.
> Misc metastore changes for debuggability, error on commit txn failures
> ----------------------------------------------------------------------
>
> Key: HIVE-18349
> URL: https://issues.apache.org/jira/browse/HIVE-18349
> Project: Hive
> Issue Type: Bug
> Components: Metastore
> Affects Versions: 3.0.0
> Reporter: Prasanth Jayachandran
> Assignee: Prasanth Jayachandran
> Attachments: HIVE-18349.1.patch, HIVE-18349.2.patch,
> HIVE-18349.3.patch, HIVE-18349.4.patch, HIVE-18349.5.patch,
> HIVE-18349.6.patch, HIVE-18349.7.patch
>
>
> 1) Hive metastore audit event log/metastore log does not log the final status
> (success or failed) of the event. Some operations like for example,
> drop_table returns a boolean success flag but it never gets logged anywhere.
> However the same is sent to end event listeners or other metastore event
> listeners. It will be good to log the final status of the events.
> 2) Make connection timeout when using connection pool configurable. Currently
> its hard coded to 30 seconds.
> 3) Provide a config to enable connection leak detection for HikariCP or
> enable when debug logging is enabled.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
