[
https://issues.apache.org/jira/browse/PHOENIX-5789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17138728#comment-17138728
]
Chinmay Kulkarni edited comment on PHOENIX-5789 at 6/17/20, 6:54 PM:
---------------------------------------------------------------------
[~RichardAntal] [~stoty]
I see DropChildViewTasks logging the following warning logs which seem related
to this change:
{noformat}
2020-06-17 11:20:23,863 WARN [pool-83-thread-1]
coprocessor.TaskRegionObserver: Exception while running self healingtask. It
will be retried in the next system task table scan : taskType :
DROP_CHILD_VIEWSS.T with tenant id IS NULL and timestamp 2020-06-17
11:16:53.617
java.lang.NoClassDefFoundError: com/fasterxml/jackson/databind/ObjectMapper
at org.apache.phoenix.util.JacksonUtil.<clinit>(JacksonUtil.java:25)
at
org.apache.phoenix.coprocessor.TaskRegionObserver$SelfHealingTask.setEndTaskStatus(TaskRegionObserver.java:249)
at
org.apache.phoenix.coprocessor.TaskRegionObserver$SelfHealingTask.run(TaskRegionObserver.java:216)
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: java.lang.ClassNotFoundException:
com.fasterxml.jackson.databind.ObjectMapper
at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
... 10 more
{noformat}
Later I also saw a similar failure for one of that table's view's
dropChildViewTask (I had created a hierarchy like:
Base Table -> child view -> grandchild view):
{noformat}
2020-06-17 11:21:53,927 WARN [pool-83-thread-1]
coprocessor.TaskRegionObserver: Exception while running self healingtask. It
will be retried in the next system task table scan : taskType :
DROP_CHILD_VIEWSS1.V3 with tenant id IS NULL and timestamp 2020-06-17
11:20:18.839
java.lang.NoClassDefFoundError: Could not initialize class
org.apache.phoenix.util.JacksonUtil
at
org.apache.phoenix.coprocessor.TaskRegionObserver$SelfHealingTask.setEndTaskStatus(TaskRegionObserver.java:249)
at
org.apache.phoenix.coprocessor.TaskRegionObserver$SelfHealingTask.run(TaskRegionObserver.java:216)
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)
{noformat}
All in all, it looks like the task gets executed successfully however the step
to set the end status fails
([here|https://github.com/apache/phoenix/blame/4.x/phoenix-core/src/main/java/org/apache/phoenix/coprocessor/TaskRegionObserver.java#L242])
since my SYSTEM.TASK still looks like this:
!Screen Shot 2020-06-17 at 11.45.44 AM.png|width=750!
If we have logic to keep retrying tasks that haven't succeeded, this can lead
to the same tasks being run again and again which is obviously bad.
Can you guys please take a look?
was (Author: ckulkarni):
[~RichardAntal] [~stoty]
I see DropChildViewTasks failing with the following exception which seem
related to this change:
{noformat}
2020-06-17 11:20:23,863 WARN [pool-83-thread-1]
coprocessor.TaskRegionObserver: Exception while running self healingtask. It
will be retried in the next system task table scan : taskType :
DROP_CHILD_VIEWSS.T with tenant id IS NULL and timestamp 2020-06-17
11:16:53.617
java.lang.NoClassDefFoundError: com/fasterxml/jackson/databind/ObjectMapper
at org.apache.phoenix.util.JacksonUtil.<clinit>(JacksonUtil.java:25)
at
org.apache.phoenix.coprocessor.TaskRegionObserver$SelfHealingTask.setEndTaskStatus(TaskRegionObserver.java:249)
at
org.apache.phoenix.coprocessor.TaskRegionObserver$SelfHealingTask.run(TaskRegionObserver.java:216)
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: java.lang.ClassNotFoundException:
com.fasterxml.jackson.databind.ObjectMapper
at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
... 10 more
{noformat}
Later I also saw a similar failure for one of that table's view's
dropChildViewTask (I had created a hierarchy like:
Base Table -> child view -> grandchild view):
{noformat}
2020-06-17 11:21:53,927 WARN [pool-83-thread-1]
coprocessor.TaskRegionObserver: Exception while running self healingtask. It
will be retried in the next system task table scan : taskType :
DROP_CHILD_VIEWSS1.V3 with tenant id IS NULL and timestamp 2020-06-17
11:20:18.839
java.lang.NoClassDefFoundError: Could not initialize class
org.apache.phoenix.util.JacksonUtil
at
org.apache.phoenix.coprocessor.TaskRegionObserver$SelfHealingTask.setEndTaskStatus(TaskRegionObserver.java:249)
at
org.apache.phoenix.coprocessor.TaskRegionObserver$SelfHealingTask.run(TaskRegionObserver.java:216)
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)
{noformat}
All in all, it looks like the task gets executed successfully however the step
to set the end status fails
([here|https://github.com/apache/phoenix/blame/4.x/phoenix-core/src/main/java/org/apache/phoenix/coprocessor/TaskRegionObserver.java#L242])
since my SYSTEM.TASK still looks like this:
!Screen Shot 2020-06-17 at 11.45.44 AM.png|width=750!
Can you guys please take a look?
> try to standardize on a JSON library
> ------------------------------------
>
> Key: PHOENIX-5789
> URL: https://issues.apache.org/jira/browse/PHOENIX-5789
> Project: Phoenix
> Issue Type: Improvement
> Components: core
> Reporter: Istvan Toth
> Assignee: Richard Antal
> Priority: Minor
> Fix For: 5.1.0, 4.16.0
>
> Attachments: PHOENIX-5789.4.x.v1.patch, PHOENIX-5789.4.x.v3.patch,
> PHOENIX-5789.4.x.v4.patch, PHOENIX-5789.4.x.v5.patch,
> PHOENIX-5789.4.x.v6.patch, PHOENIX-5789.4.x.v7.patch,
> PHOENIX-5789.master.addendum.patch, PHOENIX-5789.master.addendum.v2.patch,
> PHOENIX-5789.master.addendum.v3.patch, PHOENIX-5789.master.v1.patch,
> PHOENIX-5789.master.v2.patch, PHOENIX-5789.master.v3.patch,
> PHOENIX-5789.master.v4.patch, Screen Shot 2020-06-17 at 11.45.44 AM.png
>
>
> Phoenix uses at least the following JSON libraries:
> * gson
> * jackson
> * jettison
> Of these, only the jackson usage is performance critical, as it is used
> during bulk loading.
> Try to standardize on a single one to reduce dependency hell.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
