[ https://issues.apache.org/jira/browse/HBASE-3643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13549917#comment-13549917 ]
stack commented on HBASE-3643: ------------------------------ We should at least try this for 0.96... Can punt if too much work. > 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 For more information on JIRA, see: http://www.atlassian.com/software/jira