[
https://issues.apache.org/jira/browse/HBASE-3643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu updated HBASE-3643:
--------------------------
Fix Version/s: (was: 0.92.0)
0.94.0
> Close the filesystem handle when HRS is aborting
> ------------------------------------------------
>
> Key: HBASE-3643
> URL: https://issues.apache.org/jira/browse/HBASE-3643
> Project: HBase
> Issue Type: Improvement
> Affects Versions: 0.90.1
> Reporter: Jean-Daniel Cryans
> Priority: Critical
> Fix For: 0.94.0
>
>
> I thought of a way to fix HBASE-3515 that has a very broad impact, so I'm
> creating this jira to *raise awareness* and gather comments.
> Currently when we call HRS.abort, it's still possible to do HDFS operations
> like rolling logs and flushing files. It also has the impact that some
> threads cannot write to ZK (like the situation described in HBASE-3515) but
> then can still write to HDFS. Since that call is so central, I think we
> should {color:red} add fs.close() inside the abort method{color}.
> The impact of this is that everything else that happens after the close call,
> like closing files or appending, will fail in the most horrible ways. On the
> bright side, this means less disruptive changes on HDFS.
> Todd pointed at HBASE-2231 as related, but I think my solution is still too
> sloppy as we could still finish a compaction and immediately close the
> filesystem after that (damage's done).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
