[
https://issues.apache.org/jira/browse/HBASE-3643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13634215#comment-13634215
]
Sergey Shelukhin commented on HBASE-3643:
-----------------------------------------
-0 from me... While it does narrow the gap it offends my engineering
sensibilities :)
It can also introduce bugs, such as the one we saw not so long ago where FS
closing while the region was closing caused some problem.
Perhaps we can do it and then back it off when we have proper solution? Proper
solution is marked as critical so it could be soon...
> 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.95.1
>
>
> 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
For more information on JIRA, see: http://www.atlassian.com/software/jira