[
https://issues.apache.org/jira/browse/OAK-4667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15417399#comment-15417399
]
Andrei Dulceanu edited comment on OAK-4667 at 8/11/16 3:17 PM:
---------------------------------------------------------------
Attaching a first draft of the test which is currently incorrectly failing IMO.
The current test reports a reclaimed size of {{330240 bytes}}, for 5 threads,
each creating a {{65536 bytes}} blob. So more or less it looks like everything
is cleaned up, although this should not happen.
Now if I take the same code and replace the line in [1] with
{{concurrentWriteTask.run()}}, basically serialising all writes to the
repository, then an expected {{0 bytes}} reclaimed size shows up.
Moreover this is the list of tar files generated by the parallel version:
||Size||Time||Name||
|5.0K|Aug 11 11:16|data00000a.tar|
|5.0K|Aug 11 11:16|data00000b.tar|
|336K|Aug 11 11:16|data00001a.tar|
and here's the tar file generated by the serialised version:
||Size||Time||Name||
|333K|Aug 11 11:16|data00000a.tar|
Another important thing: the previous implementation of reclaimed size (pre
OAK-4601) correctly reports {{0 bytes}} for serialised version of the test (as
the current one), but fails reporting various negative sizes (depending on the
threads scheduling) for the parallel version (as expected).
/cc [~mduerig] [~alexparvulescu]
was (Author: dulceanu):
Attaching a first draft of the test which is currently incorrectly failing IMO.
The current test reports a reclaimed size of {{330240 bytes}}, for 5 threads,
each creating a {{65536 bytes}} blob. So more or less it looks like everything
is cleaned up, although this should not happen.
Now if I take the same code and replace the line in [1] with
{{concurrentWriteTask.run()}}, basically serialising all writes to the
repository, then an expected {{0 bytes}} reclaimed size shows up.
Moreover this is the list of tar files generated by the parallel version:
||Size||Time||Name||
|5.0K|Aug 11 11:16|data00000a.tar|
|5.0K|Aug 11 11:16|data00000b.tar|
|336K|Aug 11 11:16|data00001a.tar|
and here's the tar file generated by the serialised version:
||Size||Time||Name||
|333K|Aug 11 11:16|data00000a.tar|
/cc [~mduerig] [~alexparvulescu]
> Create IT to validate that reclaimed size after cleanup is always positive
> --------------------------------------------------------------------------
>
> Key: OAK-4667
> URL: https://issues.apache.org/jira/browse/OAK-4667
> Project: Jackrabbit Oak
> Issue Type: Test
> Components: segment-tar
> Affects Versions: Segment Tar 0.0.10
> Reporter: Andrei Dulceanu
> Assignee: Andrei Dulceanu
> Priority: Minor
> Attachments: OAK-4667-01.patch
>
>
> As OAK-4106 reworked the way {{reclaimedSize}} is computed, it would be nice
> to have an IT to validate the assumption that under the new circumstances
> this value is always positive. Of particular interest here is the scenario in
> which concurrent writes interweave with the cleanup process.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
