[
https://issues.apache.org/jira/browse/PHOENIX-5545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16973752#comment-16973752
]
Chinmay Kulkarni edited comment on PHOENIX-5545 at 11/13/19 10:14 PM:
----------------------------------------------------------------------
Both ITs pass when I run them locally.
It looks like we call flushParentPhysicalTable if dropMetadata is true and
this calls flushTable on the underlying physical base table.
When we drop a view that has an index as a result of a DropChildViewsTask, the
base table was already previously dropped, so the flushTable call would fail
with the TNFE.
In case of a DROP INDEX also we end up calling flushTable if dropMetadata is
true. So, in this case as well, if the base table was already/simultaneously
dropped, the flushTable would fail with the TNFE.
I think it is safe to catch the TNFE and log this at the flushTable level in
[here|https://github.com/apache/phoenix/blob/4becb2b2aa95aa74f5339493d97ed9b3dd0c5396/phoenix-core/src/main/java/org/apache/phoenix/query/ConnectionQueryServicesImpl.java#L1901]
rather than handle it specifically for the case of DropChildViewTask like I
did in my
[PR|https://github.com/apache/phoenix/blob/30ff6d2a9bf0357874c2bd6849190f4de0595b55/phoenix-core/src/main/java/org/apache/phoenix/util/ViewUtil.java#L223].
Besides, when we call
[dropTables|https://github.com/apache/phoenix/blob/4becb2b2aa95aa74f5339493d97ed9b3dd0c5396/phoenix-core/src/main/java/org/apache/phoenix/query/ConnectionQueryServicesImpl.java#L1902]
later, we are also swallowing the TNFE
[here|https://github.com/apache/phoenix/blob/4becb2b2aa95aa74f5339493d97ed9b3dd0c5396/phoenix-core/src/main/java/org/apache/phoenix/query/ConnectionQueryServicesImpl.java#L1997].
WDYT [~larsh] [~tdsilva]?
Edit: OR, as Lars mentioned above, just remove the flushTable stuff, but I'm
not fully aware of any other implications that might have.
was (Author: ckulkarni):
Both ITs pass when I run them locally.
It looks like we call flushParentPhysicalTable if dropMetadata is true and
this calls flushTable on the underlying physical base table.
When we drop a view that has an index as a result of a DropChildViewsTask, the
base table was already previously dropped, so the flushTable call would fail
with the TNFE.
In case of a DROP INDEX also we end up calling flushTable if dropMetadata is
true. So, in this case as well, if the base table was already/simultaneously
dropped, the flushTable would fail with the TNFE.
I think it is safe to catch the TNFE and log this at the flushTable level in
[here|https://github.com/apache/phoenix/blob/4becb2b2aa95aa74f5339493d97ed9b3dd0c5396/phoenix-core/src/main/java/org/apache/phoenix/query/ConnectionQueryServicesImpl.java#L1901]
rather than handle it specifically for the case of DropChildViewTask like I
did in my
[PR|https://github.com/apache/phoenix/blob/30ff6d2a9bf0357874c2bd6849190f4de0595b55/phoenix-core/src/main/java/org/apache/phoenix/util/ViewUtil.java#L223].
Besides, when we call
[dropTables|https://github.com/apache/phoenix/blob/4becb2b2aa95aa74f5339493d97ed9b3dd0c5396/phoenix-core/src/main/java/org/apache/phoenix/query/ConnectionQueryServicesImpl.java#L1902]
later, we are also swallowing the TNFE
[here|https://github.com/apache/phoenix/blob/4becb2b2aa95aa74f5339493d97ed9b3dd0c5396/phoenix-core/src/main/java/org/apache/phoenix/query/ConnectionQueryServicesImpl.java#L1997].
WDYT [~larsh] [~tdsilva]?
> DropChildViews Task fails for a base table when its child view has an index
> ---------------------------------------------------------------------------
>
> Key: PHOENIX-5545
> URL: https://issues.apache.org/jira/browse/PHOENIX-5545
> Project: Phoenix
> Issue Type: Bug
> Affects Versions: 4.15.0, 5.1.0
> Reporter: Chinmay Kulkarni
> Assignee: Chinmay Kulkarni
> Priority: Major
> Fix For: 4.15.0, 5.1.0
>
> Attachments: PHOENIX-5545-4.x-HBase-1.3-v1.patch
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> 1) Start the HBase server with 4.15.0 Phoenix
> 2) Connect with a 4.15.0 client
> 3) Create a base table and a view on top of the base table and create an
> index on top of this view:
> {code:sql}
> CREATE TABLE IF NOT EXISTS Z_BASE_TABLE (ID INTEGER NOT NULL PRIMARY KEY,
> HOST VARCHAR(10), FLAG BOOLEAN);
> CREATE VIEW Z_VIEW1 (col1 INTEGER, col2 INTEGER, col3 INTEGER, col4 INTEGER,
> col5 INTEGER) AS SELECT * FROM Z_BASE_TABLE WHERE ID>10;
> CREATE INDEX V_I ON Z_VIEW1(COL4);
> {code}
> 4) Drop the base table with the cascade option:
> {code:sql}
> DROP TABLE Z_BASE_TABLE CASCADE;
> {code}
> 5) DropChildViewsTask gets added to the SYSTEM.TASK table as expected, but
> when it gets scheduled and subsequently executed, it fails with the following
> exception:
> {code:java}
> 2019-10-24 22:44:34,214 ERROR [pool-121-thread-1] tasks.DropChildViewsTask:
> Exception while dropping a child view task. null.Z_BASE_TABLE with tenant id
> IS NULL and timestamp 292278994-08-16 23:12:55.807
> org.apache.phoenix.exception.PhoenixIOException: Z_BASE_TABLE
> at
> org.apache.phoenix.query.ConnectionQueryServicesImpl.flushTable(ConnectionQueryServicesImpl.java:4442)
> at
> org.apache.phoenix.query.ConnectionQueryServicesImpl.flushParentPhysicalTable(ConnectionQueryServicesImpl.java:1922)
> at
> org.apache.phoenix.query.ConnectionQueryServicesImpl.dropTable(ConnectionQueryServicesImpl.java:1888)
> at
> org.apache.phoenix.schema.MetaDataClient.dropTable(MetaDataClient.java:3152)
> at
> org.apache.phoenix.schema.MetaDataClient.dropTable(MetaDataClient.java:3060)
> at org.apache.phoenix.util.ViewUtil.dropChildViews(ViewUtil.java:207)
> at
> org.apache.phoenix.coprocessor.tasks.DropChildViewsTask.run(DropChildViewsTask.java:60)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.phoenix.coprocessor.TaskRegionObserver$SelfHealingTask.run(TaskRegionObserver.java:204)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: org.apache.hadoop.hbase.TableNotFoundException: Z_BASE_TABLE
> at
> org.apache.hadoop.hbase.client.HBaseAdmin.checkTableExists(HBaseAdmin.java:2863)
> at org.apache.hadoop.hbase.client.HBaseAdmin.flush(HBaseAdmin.java:1904)
> at org.apache.hadoop.hbase.client.HBaseAdmin.flush(HBaseAdmin.java:1949)
> at
> org.apache.phoenix.query.ConnectionQueryServicesImpl.flushTable(ConnectionQueryServicesImpl.java:4440)
> ... 18 more
> {code}
> Note that this marks the DropChildViews task for the base table as failed and
> so *if the base table has any other views, those views will also not be
> dropped*.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
