[
https://issues.apache.org/jira/browse/HBASE-6778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14284612#comment-14284612
]
Jonathan Lawlor commented on HBASE-6778:
----------------------------------------
Thanks for the feedback [~stack]. I have modified the implementation to take
into account most of this feedback, but I do have a few clarifying questions
that are due to my inexperience with the codebase:
1. When you say that ChoreService should be at the top level I'm not quite sure
what you mean. With the current Chore workflow, a class creates an instance of
a Chore, and since that Chore contains a thread, scheduling that chore to run
simply requires starting the thread.
In contrast, the workflow that we are trying to move to would require a
ScheduledChore instance to be created and then offered to a ChoreService
instance for scheduling. I'm wondering where the instance of the ChoreService
would live (i.e. is there a static class that I could create an instance of
ChoreService in and then expose public scheduling methods).
2. In terms of backfilling the doc before the final patch, I'm not sure where
this information would go. Would you be able to point me in the right direction
here (or maybe there is a commit that I could review to see how it's typically
done).
3. In order to tighten up the class so that certain methods are visible only
for testing, would adding the "@VisibleForTesting" annotation suffice, or is
there more to it than that?
4. The onChoreMissedStartTime is currently exposed publicly so that chores can
tell the ChoreService that they are scheduled with that they have missed their
start time. The ChoreService can subsequently make the decision as to whether
or not this event should cause an increase in the core pool thread count. If
this method isn't exposed VIA the ChoreServicer interface, I'm unsure of how to
achieve a similar event flow.
In terms of the reschedule method: it was added as a side effect of the new
workflow. Specifically, in the case that a ScheduledChore misses its start
time, we reschedule it immediately so that the ScheduledThreadPoolExecutor no
longer regards it as a delayed task (this is important since the
ScheduledThreadPoolExecutor assigns threads to waiting tasks based on how long
the tasks have waited -> tasks with a larger delay have a higher priority ->
thus rescheduling the task prevents that chore from hogging a thread).
> Deprecate Chore; its a thread per task when we should have one thread to do
> all tasks
> -------------------------------------------------------------------------------------
>
> Key: HBASE-6778
> URL: https://issues.apache.org/jira/browse/HBASE-6778
> Project: HBase
> Issue Type: Bug
> Reporter: stack
> Assignee: Jonathan Lawlor
> Attachments: HBASE_6778_WIP_v1.patch, thread_dump_HMaster.local.out
>
>
> Should use something like ScheduledThreadPoolExecutor instead (Elliott said
> this first I think; J-D said something similar just now).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
