You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hive.apache.org by "Alexander Kolbasov (JIRA)" <ji...@apache.org> on 2018/03/26 04:12:00 UTC
[jira] [Comment Edited] (HIVE-18885) DbNotificationListener has a
deadlock between Java and DB locks (2.x line)
[ https://issues.apache.org/jira/browse/HIVE-18885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16413356#comment-16413356 ]
Alexander Kolbasov edited comment on HIVE-18885 at 3/26/18 4:11 AM:
--------------------------------------------------------------------
Looks like you are fixing two problems at once. One is described here and is only applicable to branch-3. The second poblem (cleaner thread throwing exception) is applicable to branch-3 as well, so I suggest using a separate JIRA for it.
As for the fix for the second problem, I think you need to catch {{Throwable}}, not just {{Exception}} to guarantee that the cleaner thread will survive.
A few more thoughts:
# The comment for the {{DbNotificationListener}} class is stale and should be updated.
# CleanerThread is static, which is Ok, but better to guarantee that the whole thing is a singleton.
# It would be nice to have a custom name for a cleaner thread.
I don't mean that all of these should be done in this patch - probably it is best to just remove the lock here and do cleaner-thread improvements as a separate JIRA (or two) since they are valid for both branch-2 and branch-3.
was (Author: akolb):
Looks like you are fixing two problems at once. One is described here and is only applicable to branch-3. The second poblem (cleaner thread throwing exception) is applicable to branch-3 as well, so I suggest using a separate JIRA for it.
As for the fix for the second problem, I think you need to catch Throwable, not just Exception to guarantee that the cleaner thread will survive.
A few more thoughts:
# The comment for the {{DbNotificationListener}} class is stale and should be updated.
# CleanerThread is static, which is Ok, but better to guarantee that the whole thing is a singleton.
# It would be nice to have a custom name for a cleaner thread.
I don't mean that all of these should be done in this patch - probably it is best to just remove the lock here and do cleaner-thread improvements as a separate JIRA (or two) since they are valid for both branch-2 and branch-3.
> DbNotificationListener has a deadlock between Java and DB locks (2.x line)
> --------------------------------------------------------------------------
>
> Key: HIVE-18885
> URL: https://issues.apache.org/jira/browse/HIVE-18885
> Project: Hive
> Issue Type: Bug
> Components: Hive, Metastore
> Affects Versions: 2.3.2
> Reporter: Alexander Kolbasov
> Assignee: Vihang Karajgaonkar
> Priority: Major
> Attachments: HIVE-18885.01.branch-2.patch, HIVE-18885.02.branch-2.patch
>
>
> You can see the problem from looking at the code, but it actually created severe problems for real life Hive user.
> When {{alter table}} has {{cascade}} option it does the following:
> {code:java}
> msdb.openTransaction()
> ...
> List<Partition> parts = msdb.getPartitions(dbname, name, -1);
> for (Partition part : parts) {
> List<FieldSchema> oldCols = part.getSd().getCols();
> part.getSd().setCols(newt.getSd().getCols());
> String oldPartName = Warehouse.makePartName(oldt.getPartitionKeys(), part.getValues());
> updatePartColumnStatsForAlterColumns(msdb, part, oldPartName, part.getValues(), oldCols, part);
> msdb.alterPartition(dbname, name, part.getValues(), part);
> }
> {code}
> So it walks all partitions (and this may be huge list) and does some non-trivial operations in one single uber-transaction.
> When DbNotificationListener is enabled, it adds an event for each partition, all while
> holding a row lock on NOTIFICATION_SEQUENCE table. As a result, while this is happening no other write DDL can proceed. This can sometimes cause DB lock timeouts which cause HMS level operation retries which make things even worse.
> In one particular case this pretty much made HMS unusable.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)