[
https://issues.apache.org/jira/browse/HBASE-3643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars Hofhansl updated HBASE-3643:
---------------------------------
Fix Version/s: (was: 0.94.0)
0.96.0
Pushing to 0.96, pull back if you feel differntly.
> 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.96.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.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
