[
https://issues.apache.org/jira/browse/HBASE-12028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14237313#comment-14237313
]
Alicia Ying Shu commented on HBASE-12028:
-----------------------------------------
Modified the patch a little bit. Set the default for whether to abort region
server when handlers die to be false. User can configure it to be true. Keep
existing behavior not closing client connection when Rpc handler thread dies
since client can close the connection when needed. Otherwise, we may run into
race condition that both client and server want to close the connection at the
same time.
> Abort the RegionServer, when one of it's handler threads die
> ------------------------------------------------------------
>
> Key: HBASE-12028
> URL: https://issues.apache.org/jira/browse/HBASE-12028
> Project: HBase
> Issue Type: Bug
> Components: regionserver
> Reporter: Sudarshan Kadambi
> Assignee: Alicia Ying Shu
> Attachments: Hbase-12028.patch
>
>
> Over in HBase-11813, a user identified an issue where in all the RPC handler
> threads would exit with StackOverflow errors due to an unchecked
> recursion-terminating condition. Our clusters demonstrated the same trace.
> While the patch posted for HBASE-11813 got our clusters to be merry again,
> the breakdown surfaced some larger issues.
> When the RegionServer had all it's RPC handler threads dead, it continued to
> have regions assigned it. Clearly, it wouldn't be able to serve reads and
> writes on those regions. A second issue was that when a user tried to disable
> or drop a table, the master would try to communicate to the regionserver for
> region unassignment. Since the same handler threads seem to be used for
> master <-> RS communication as well, the master ended up hanging on the RS
> indefinitely. Eventually, the master stopped responding to all table
> meta-operations.
> A handler thread should never exit, and if it does, it seems like the more
> prudent thing to do would be for the RS to abort. This way, at least recovery
> can be undertaken and the regions could be reassigned elsewhere. I also think
> that the master<->RS communication should get its own exclusive threadpool,
> but I'll wait until this issue has been sufficiently discussed before opening
> an issue ticket for that.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
