You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Jean-Daniel Cryans (JIRA)" <ji...@apache.org> on 2011/03/15 01:59:29 UTC
[jira] Created: (HBASE-3643) Close the filesystem handle when HRS
is aborting
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.92.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
[jira] [Updated] (HBASE-3643) Close the filesystem handle when HRS
is aborting
Posted by "Ted Yu (JIRA)" <ji...@apache.org>.
[ 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
[jira] Commented: (HBASE-3643) Close the filesystem handle when HRS
is aborting
Posted by "stack (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-3643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006800#comment-13006800 ]
stack commented on HBASE-3643:
------------------------------
Ohh... radical. It might work. I mean, when abort flag is set, we'll skip out closing regions. Have you tried it? Most tests should pass since a while back we made sure each RS and Master were their own user when using HDFS.
> 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.92.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
[jira] [Updated] (HBASE-3643) Close the filesystem handle when HRS
is aborting
Posted by "Lars Hofhansl (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-3643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Lars Hofhansl updated HBASE-3643:
---------------------------------
I assume we don't want to do this in 0.94?
> 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.
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
[jira] [Updated] (HBASE-3643) Close the filesystem handle when HRS
is aborting
Posted by "Lars Hofhansl (Updated) (JIRA)" <ji...@apache.org>.
[ 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