[
https://issues.apache.org/jira/browse/OAK-4054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15167038#comment-15167038
]
Alex Parvulescu commented on OAK-4054:
--------------------------------------
bq. Not sure about the fall out this would generate though and whether we
should target it for 1.4.
I would hold this out from 1.4. I saw this method when looking at the
SegmentWriter#writeNode, and I think it has merit in the idea that the check
needs to be _really_ fast when you write nodes, otherwise you are stuck cycling
through the readers and the writer (protected by a read lock) on each call, not
too good for performance. at the very least we need to benchmark this properly
before taking it out.
what if you replace this {{id.getTracker() == tracker}} with a more interesting
metric, something that includes gc generation, so that the store performs this
potentially expensive check only in the cases where a given item is considered
old?
> FileStore.containsSegment returns alway true (almost)
> -----------------------------------------------------
>
> Key: OAK-4054
> URL: https://issues.apache.org/jira/browse/OAK-4054
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segmentmk
> Reporter: Michael Dürig
> Assignee: Michael Dürig
> Priority: Critical
> Labels: compaction, gc, stability
> Fix For: 1.4
>
>
> {{FileStore.containsSegment()}} looks
> [funky|https://github.com/mduerig/jackrabbit-oak/blob/36cb3bf6e5078e3afa75581fb789eeca7b5df2e2/oak-segment/src/main/java/org/apache/jackrabbit/oak/plugins/segment/file/FileStore.java#L1197-L1197].
> This "optimisation" causes it to always return {{true}}.
> {{containsSegment}} is used for deduplication and revision gc. The current
> implementation causes {{SNFE}} exceptions once gc is effective (as I
> experienced while working on OAK-3348).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
