[
https://issues.apache.org/jira/browse/HIVE-25144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17360102#comment-17360102
]
David Mollitor commented on HIVE-25144:
---------------------------------------
OK, I've been looking at this all wrong. This is all happening internal to
HMS. I thought it was the HMS-client retrying. This should be removed. This
is very confusing, hides transient errors, and looking at the code, seems very
error-prone and fragile as the project changes. If an HMS error occurs, it
should report back to the client and let the client decide how it wants to
handle the error. For example, the client may want to re-try the request with
a different instance of HMS instead of waiting for this one to try N times and
fail.
> Remove RetryingHMSHandler
> -------------------------
>
> Key: HIVE-25144
> URL: https://issues.apache.org/jira/browse/HIVE-25144
> Project: Hive
> Issue Type: Improvement
> Reporter: David Mollitor
> Assignee: David Mollitor
> Priority: Major
> Labels: pull-request-available
> Time Spent: 50m
> Remaining Estimate: 0h
>
> I have recently seen an issue where a Hive {{CREATE TABLE}} method fails with
> {{AlreadyExistsException}} even though the table does absolutely not exist.
>
> I believe the issue is there there is a timeout/transient error with HMS and
> the backend database. So, the client submits the request to HMS, and the
> request does eventually succeed, but only after the connection to the client
> connects. Therefore, when the HMS Client "retry" functionality kicks it, the
> second time around, the table looks like it already exists.
>
> If something goes wrong during a HMS CREATE operation, we do not know the
> state of the operation and therefore it should just fail.
>
> It would certainly be more transparent to the end-user what is going on. An
> {{AlreadyExistsException}} is confusing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
