[
https://issues.apache.org/jira/browse/HBASE-19527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16294488#comment-16294488
]
Appy edited comment on HBASE-19527 at 12/18/17 3:32 AM:
--------------------------------------------------------
Other cases are (looking for things calling ExecutorService#submit()):
CompactedHFilesDischarger (chore), RegionReplicaFlushHandler,
CloseRegionHandler, OpenMetaHandler, OpenPriorityRegionHandler,
OpenRegionHandler.
Am good with the idea of trying it. The effects of this one line change are
much profound and we should address them too. For eg.
- The check of if(rs.isStopping) in these handlers will be confusing. They will
suggest that those are the only exit point in the flow, but in fact they are
not. We should either remove them, but maybe they make sense (to avoid starting
new work), in which case there should at least be a comment in each place
stating the same.
bq. I needed to keep a thread running until the last moment and didn't want to
check stopped or aborted flags because these were being set too early in the
shutdown process. Thats how I arrrived here. The thread that messages master
about region changed state was ending abruptly as soon as the RS set 'stop'
which it does early when a cluster is going down. Even after 'stop' is set, we
still have the close of all regions to be done..... With the messaging thread
killed, the notice does not get to Master that a region has been closed.
This gives a nice example to think about.
Is the messaging thread daemon or not? (seems to me it is not) Is there a
separate jira what you tackling this problem? Add a comment somewhere on this
dependency of closing regions and messaging and how daemon threads help it?
In summary, making these threads daemon makes sense. Although might break
current assumptions and maybe logic. Although one line change, it has deeper
effects, and the very least should document new assumptions in relevant places.
Edit: +1, but needs adding comments.
was (Author: appy):
Other cases are (looking for things calling ExecutorService#submit()):
CompactedHFilesDischarger (chore), RegionReplicaFlushHandler,
CloseRegionHandler, OpenMetaHandler, OpenPriorityRegionHandler,
OpenRegionHandler.
Am good with the idea of trying it. The effects of this one line change are
much profound and we should address them too. For eg.
- The check of if(rs.isStopping) in these handlers will be confusing. They will
suggest that those are the only exit point in the flow, but in fact they are
not. We should either remove them, but maybe they make sense (to avoid starting
new work), in which case there should at least be a comment in each place
stating the same.
bq. I needed to keep a thread running until the last moment and didn't want to
check stopped or aborted flags because these were being set too early in the
shutdown process. Thats how I arrrived here. The thread that messages master
about region changed state was ending abruptly as soon as the RS set 'stop'
which it does early when a cluster is going down. Even after 'stop' is set, we
still have the close of all regions to be done..... With the messaging thread
killed, the notice does not get to Master that a region has been closed.
This gives a nice example to think about.
Is the messaging thread daemon or not? (seems to me it is not) Is there a
separate jira what you tackling this problem? Add a comment somewhere on this
dependency of closing regions and messaging and how daemon threads help it?
In summary, making these threads daemon makes sense. Although might break
current assumptions and maybe logic. Although one line change, it has deeper
effects, and the very least should document new assumptions in relevant places.
> Make ExecutorService threads daemon=true.
> -----------------------------------------
>
> Key: HBASE-19527
> URL: https://issues.apache.org/jira/browse/HBASE-19527
> Project: HBase
> Issue Type: Bug
> Reporter: stack
> Assignee: stack
> Attachments: HBASE-19527.master.001.patch,
> HBASE-19527.master.001.patch, HBASE-19527.master.001.patch
>
>
> Let me try this. ExecutorService runs OPENs, CLOSE, etc. If Server is going
> down, no point in these threads sticking around (I think). Let me try this.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
