[
https://issues.apache.org/jira/browse/HIVE-25144?focusedWorklogId=600172&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-600172
]
ASF GitHub Bot logged work on HIVE-25144:
-----------------------------------------
Author: ASF GitHub Bot
Created on: 21/May/21 04:53
Start Date: 21/May/21 04:53
Worklog Time Spent: 10m
Work Description: nrg4878 commented on pull request #2303:
URL: https://github.com/apache/hive/pull/2303#issuecomment-845651545
@belugabehr How does adding this annotation create AlreadyExistsException? I
havent looked into this in a very long time but its my recollection that this
annotation was used by either the RetryingHMSHandler or RetryingMetastoreClient
to determine whether or not to retry this operation. I would have guess it was
the RetryingHMSHandler but given this change, I suspect it is the latter.
So how exactly does this result in a AlreadyExistsException? What if the
failure was due to a DB_LOCK timeout (Where another transaction has the lock on
the table).
Also, do the implementing classes inherit annotations from the interface? I
thought it was limited to just the javadoc annotations.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
-------------------
Worklog Id: (was: 600172)
Time Spent: 0.5h (was: 20m)
> Add NoReconnect Annotation to Create AlreadyExistsException Methods
> -------------------------------------------------------------------
>
> 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: 0.5h
> 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)
