[
https://issues.apache.org/jira/browse/OAK-377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13898951#comment-13898951
]
Thomas Mueller commented on OAK-377:
------------------------------------
> The other reason I kept the lock file concept was to not unnecessarily burden
> the system by running multiple gc cycles concurrently.
If that's the only reason, I wouldn't worry about that. I think running it
multiple times concurrently should be prevented, but on a higher level (in the
GUI, in the JMX bean), but not on the low level. Trying to prevent it on a low
level is quite problematic.
> We might be able to mitigate some of the problems associated with the lock
> file existence by using flagging deleteOnExit() as you suggest
Actually, deleteOnExit will not work for lock files. If the process is killed,
the file will not be removed.
> system temp file directory
OK, that's good.
> the unit test which is passing "."
Yes, or use the directory "/target" in unit tests. This is to ensure files are
removed when the build stops (or fails).
> Data store garbage collection
> -----------------------------
>
> Key: OAK-377
> URL: https://issues.apache.org/jira/browse/OAK-377
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, mk
> Reporter: Thomas Mueller
> Assignee: Thomas Mueller
> Fix For: 0.17
>
> Attachments: OAK-377.patch
>
>
> Unused binaries in the data store need to be garbage collected.
> There is a partial implementation in oak-mk, however it is currently not run
> (not run automatically, and I think there is no way to run it manually).
> Also, we might want to investigate in faster garbage collection algorithms:
> young generation garbage collection, or garbage collection using reference
> counting (for example using an index of references to the data store).
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
