[
https://issues.apache.org/jira/browse/HBASE-15436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15196687#comment-15196687
]
Naganarasimha G R commented on HBASE-15436:
-------------------------------------------
Thanks for looking into it [~anoopsamjohn],
bq. So this kind of a scenario the application should take care? I mean
shutdown the clients ( The NMs in this case) before HBase cluster down
Well this could be a OM/admin operation which i think YARN/platform will have
less control off. And also in my case it was happening due HBASE master and
Region server going down abruptly due to connectivity problems with zookeeper.
I have attached the HBase logs last when i faced in 1.0.3 in YARN-4736.
I faced this issue when trying to test ATS Next Gen with Hbase in Pseudo
cluster and it was easily reproduced when zookeeper data folder was set to
default {{tmp/hbase-<username>}}. Not sure whether its coincidence or the cause.
> BufferedMutatorImpl.flush() appears to get stuck
> ------------------------------------------------
>
> Key: HBASE-15436
> URL: https://issues.apache.org/jira/browse/HBASE-15436
> Project: HBase
> Issue Type: Bug
> Components: Client
> Affects Versions: 1.0.2
> Reporter: Sangjin Lee
> Attachments: hbaseException.log, threaddump.log
>
>
> We noticed an instance where the thread that was executing a flush
> ({{BufferedMutatorImpl.flush()}}) got stuck when the (local one-node) cluster
> shut down and was unable to get out of that stuck state.
> The setup is a single node HBase cluster, and apparently the cluster went
> away when the client was executing flush. The flush eventually logged a
> failure after 30+ minutes of retrying. That is understandable.
> What is unexpected is that thread is stuck in this state (i.e. in the
> {{flush()}} call). I would have expected the {{flush()}} call to return after
> the complete failure.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
