[
https://issues.apache.org/jira/browse/HBASE-3643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Kyle Purtell resolved HBASE-3643.
----------------------------------------
Resolution: Abandoned
> 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: Major
> Labels: beginner
>
> 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 was sent by Atlassian Jira
(v8.20.7#820007)
