jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dürig (JIRA) <j...@apache.org>
Subject [jira] [Comment Edited] (OAK-8209) Improve Node.isNodeType(String) performance
Date Wed, 10 Apr 2019 15:24:00 GMT

    [ https://issues.apache.org/jira/browse/OAK-8209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16814544#comment-16814544
] 

Michael Dürig edited comment on OAK-8209 at 4/10/19 3:23 PM:
-------------------------------------------------------------

{quote}I guess the real question is, can I depend on this?
{quote}
Yes I think so. This should work.
{quote}[...] refresh may update the underlying node states to reflect a remove of the tree
by another session, which would be fine as well if it is really removed.
{quote}
That's how I remember it as well. The underlying magic is implemented the way {{MemoryNodeBuilder}}
tracks transient changes. However, I'm not sure how common this usage pattern is and thus
whether you might start seeing bugs that were hidden so far.

 

Re. revision GC I don't think this is a concern. We guarantee retention for >= 1 generation
(24 hrs if GC runs daily). Older sessions will be refreshed ({{o.a.j.o.jcr.repository.RepositoryImpl.RefreshOnGC}}),
which will cause a refresh on the associated root ({{o.a.j.o.jcr.delegate.SessionDelegate#refresh}}).
Although this refresh is somewhat best effort (sessions might miss it because of race conditions),
the recommendation is not to keep sessions open for long without refreshing them. The {{types}}
{{Tree}} in {{WorkspaceImpl}} is not the only place causing \{{SNFE}}s in the case of a missed
refresh after GC.

 

 


was (Author: mduerig):
{quote}I guess the real question is, can I depend on this?
{quote}
Yes I think so. This should work.
{quote}[...] refresh may update the underlying node states to reflect a remove of the tree
by another session, which would be fine as well if it is really removed.
{quote}
That's how I remember it as well. The underlying magic is implemented the way {{MemoryNodeBuilder}}
tracks transient changes. However, I'm not sure how common this usage pattern is and thus
whether you might start seeing bugs that where hidden so far.

 

Re. revision GC I don't think this is a concern. We guarantee retention for >= 1 generation
(24 hrs if GC runs daily). Older sessions will be refreshed ({{o.a.j.o.jcr.repository.RepositoryImpl.RefreshOnGC}}),
which will cause a refresh on the associated root ({{o.a.j.o.jcr.delegate.SessionDelegate#refresh}}).
Although this refresh is somewhat best effort (sessions might miss it because of race conditions),
the recommendation is not to keep sessions open for long without refreshing them. The {{types}}
{{Tree}} in {{WorkspaceImpl}} is not the only place causing \{{SNFE}}s in the case of a missed
refresh after GC. 

 

 

> Improve Node.isNodeType(String) performance
> -------------------------------------------
>
>                 Key: OAK-8209
>                 URL: https://issues.apache.org/jira/browse/OAK-8209
>             Project: Jackrabbit Oak
>          Issue Type: Improvement
>          Components: jcr
>            Reporter: Marcel Reutegger
>            Assignee: Marcel Reutegger
>            Priority: Minor
>         Attachments: OAK-8209-RootTest.patch
>
>
> Profiling an application running on Oak showed calls to {{Node.isNodeType(String)}} as
one of the hot spots. While it may be possible to reduce those calls there's probably also
some potential in optimizing the implementation.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Mime
View raw message