[
https://issues.apache.org/jira/browse/HIVE-3537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13556343#comment-13556343
]
Namit Jain commented on HIVE-3537:
----------------------------------
Found the issue - there was a issue in the equals method for lock, whereby the
lock data was not getting fetched.
Due to that, although the lock was getting released, but hive thought that the
lock was still present, and it was again
repeatedly trying to release it before giving up.
Manually verified above tests finish normally - running the whole suite now.
> release locks at the end of move tasks
> --------------------------------------
>
> Key: HIVE-3537
> URL: https://issues.apache.org/jira/browse/HIVE-3537
> Project: Hive
> Issue Type: Bug
> Components: Locking, Query Processor
> Reporter: Namit Jain
> Assignee: Namit Jain
> Attachments: hive.3537.10.patch, hive.3537.1.patch,
> hive.3537.2.patch, hive.3537.3.patch, hive.3537.4.patch, hive.3537.5.patch,
> hive.3537.6.patch, hive.3537.7.patch, hive.3537.8.patch, hive.3537.9.patch
>
>
> Look at HIVE-3106 for details.
> In order to make sure that concurrency is not an issue for multi-table
> inserts, the current option is to introduce a dependency task, which thereby
> delays the creation of all partitions. It would be desirable to release the
> locks for the outputs as soon as the move task is completed. That way, for
> multi-table inserts, the concurrency can be enabled without delaying any
> table.
> Currently, the movetask contains a input/output, but they do not seem to be
> populated correctly.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
