You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues-all@impala.apache.org by "Quanlong Huang (Jira)" <ji...@apache.org> on 2023/03/11 08:47:00 UTC
[jira] [Commented] (IMPALA-11995) Catalog update thread should have highest priority when waiting for table locks
[ https://issues.apache.org/jira/browse/IMPALA-11995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17699193#comment-17699193 ]
Quanlong Huang commented on IMPALA-11995:
-----------------------------------------
Added the stacktrace when catalog update thread is waiting for a table read lock without timeout:
{noformat}
"Thread-8 [Getting catalog delta from version 1831]" #42 prio=5 os_prio=0 tid=0x000000000ee10000 nid=0x1f2c waiting on condition [0x00007f6dbe1f2000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x00000007252dd1c0> (a java.util.concurrent.locks.ReentrantReadWriteLock$FairSync)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:967)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1283)
at java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lock(ReentrantReadWriteLock.java:727)
at org.apache.impala.catalog.Table.takeReadLock(Table.java:265)
at org.apache.impala.catalog.CatalogServiceCatalog.lockTableAndAddToCatalogDelta(CatalogServiceCatalog.java:1431)
at org.apache.impala.catalog.CatalogServiceCatalog.addTableToCatalogDelta(CatalogServiceCatalog.java:1381)
at org.apache.impala.catalog.CatalogServiceCatalog.addDatabaseToCatalogDelta(CatalogServiceCatalog.java:1242)
at org.apache.impala.catalog.CatalogServiceCatalog.getCatalogDelta(CatalogServiceCatalog.java:914)
at org.apache.impala.service.JniCatalog.lambda$getCatalogDelta$2(JniCatalog.java:267)
at org.apache.impala.service.JniCatalog$$Lambda$26/1298414577.call(Unknown Source)
at org.apache.impala.service.JniCatalogOp.lambda$execAndSerialize$1(JniCatalogOp.java:90)
at org.apache.impala.service.JniCatalogOp$$Lambda$28/807974116.call(Unknown Source)
at org.apache.impala.service.JniCatalogOp.execOp(JniCatalogOp.java:58)
at org.apache.impala.service.JniCatalogOp.execAndSerialize(JniCatalogOp.java:89)
at org.apache.impala.service.JniCatalogOp.execAndSerialize(JniCatalogOp.java:100)
at org.apache.impala.service.JniCatalog.execAndSerialize(JniCatalog.java:230)
at org.apache.impala.service.JniCatalog.execAndSerialize(JniCatalog.java:244)
at org.apache.impala.service.JniCatalog.getCatalogDelta(JniCatalog.java:266){noformat}
BTW, we need thread annotation to show the table name.
> Catalog update thread should have highest priority when waiting for table locks
> -------------------------------------------------------------------------------
>
> Key: IMPALA-11995
> URL: https://issues.apache.org/jira/browse/IMPALA-11995
> Project: IMPALA
> Issue Type: Bug
> Components: Catalog
> Reporter: Quanlong Huang
> Assignee: Quanlong Huang
> Priority: Critical
>
> We currently use a *fair* ReentrantReadWriteLock as the table lock. Under contention, locks favor granting access to the longest-waiting thread. This could let the catalog update thread waiting until all the operations submitted before finish. The delay of catalog updates will further block queries in CREATED state.
> We should consider assigning the highest priority to the catalog update thread when waiting for table locks.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-all-unsubscribe@impala.apache.org
For additional commands, e-mail: issues-all-help@impala.apache.org