[
https://issues.redhat.com/browse/ISPN-8241?page=com.atlassian.jira.plugin...
]
Dan Berindei commented on ISPN-8241:
------------------------------------
[~dlovison] I think we can remove {{NonSegmentedRocksDBHandler}} immediately, if we put
the segment as the start of the key in {{SegmentedRocksDBHandler}}. The only advantage of
{{NonSegmentedRocksDBHandler}} that I know of is that it needs fewer open files, but that
will go away once {{SegmentedRocksDBHandler}} doesn't need one column family per
segment any more.
Even now, I believe the implementation of {{NonSegmentedRocksDBHandler#clear(IntSet)}}
uses {{clearThreshold}} wrong. It should never destroy the database when the {{segments}}
parameter is not {{null}}, otherwise it risks destroying a database that still holds data.
Finally, I'd argue that since {{clearThreshold()}} is not documented except as
"Cache store cache clear threshold." in the XSD, it's already
kind-of-deprecated. When we finally deprecate it officially and remove references to it in
the code, nobody will notice.
Refactor RocksDB clearThreshold
-------------------------------
Key: ISPN-8241
URL:
https://issues.redhat.com/browse/ISPN-8241
Project: Infinispan
Issue Type: Sub-task
Components: Loaders and Stores
Affects Versions: 9.1.0.Final
Reporter: Ryan Emerson
Assignee: Diego Lovison
Priority: Major
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-recurs...].
This has the advantage that an IOException is thrown by java.nio.file.Files::delete
--
This message was sent by Atlassian Jira
(v7.13.8#713008)