[
https://issues.apache.org/jira/browse/HDFS-11550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15936735#comment-15936735
]
Anu Engineer commented on HDFS-11550:
-------------------------------------
bq. LevelDB only allows a single process to access database at a time, so if I
want to check the data in the db
We are a single process. So that should not cause an issue.
bq. I am thinking to move the cache out, get something like
LevelDBFactory.getInstance(File dbpath) or LevelDBFactory.getInstance(String
containerName) to retrieve the instance of the database
You certainly can do that, otherwise it is trivial to support an isEmpty
function in the LevelDB class and you can get the instance from the keyImpl and
invoke that function.
There is also a long term perspective that we should take, once the Ratis
related changes are in (HDFS-11519), we might want to go back and look at if we
should break up the container layer into two. That is a layer that deals with
the network protocol and a real storage layer (actually this can be done even
without HDFS-11519). When I originally wrote it I was anticipating the Ratis
work would replace this work, but it seems that Ratis layer is just reusing the
current storage stack. So may thinking about that (but not really linking it
with this JIRA) is also useful.
> Ozone: Add a check to prevent removing a container that has keys in it
> ----------------------------------------------------------------------
>
> Key: HDFS-11550
> URL: https://issues.apache.org/jira/browse/HDFS-11550
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: ozone
> Affects Versions: HDFS-7240
> Reporter: Weiwei Yang
> Assignee: Weiwei Yang
>
> The Storage Container remove call must check if there are keys in the
> container before removing itself. if not it should return an error,
> ERROR_CONTAINER_NOT_EMPTY.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
