[infinispan-issues] [JBoss JIRA] (ISPN-8241) Refactor RocksDB clearThreshold

[William Burns (JIRA)]

    [ https://issues.jboss.org/browse/ISPN-8241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13607505#comment-13607505 ] 

William Burns commented on ISPN-8241:
-------------------------------------

It should be noted that this horrendously slow if there aren't that many entries in the database (in comparison to just invoking delete). We may however need to compact the files after deletes maybe?

> Refactor RocksDB clearThreshold
> -------------------------------
>
>                 Key: ISPN-8241
>                 URL: https://issues.jboss.org/browse/ISPN-8241
>             Project: Infinispan
>          Issue Type: Sub-task
>          Components: Loaders and Stores
>    Affects Versions: 9.1.0.Final
>            Reporter: Ryan Emerson
>            Assignee: Ryan Emerson
>             Fix For: 9.4.0.Final
>
>
> Currently the RocksDB store utilises a "clearThreshold" to try to delete entries individually before deleting and re-initiating the database. We should deprecate this threshold and always delete/reinit the database. 
> Currently when deleting the database, we utilise Util.recursiveFileRemove which does not confirm that the file has actually been deleted. Instead, we should provide a nio based implementation instead, similar to the one stated [here|https://stackoverflow.com/questions/779519/delete-directories-recursively-in-java/27917071#27917071]. This has the advantage that an IOException is thrown by java.nio.file.Files::delete



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)