jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergiy Shyrkov (JIRA)" <j...@apache.org>
Subject [jira] [Created] (JCR-3560) CachingHierarchyManager.stateDiscarded() call to provider.hasItemState(discarded.getId())
Date Thu, 04 Apr 2013 21:14:16 GMT
Sergiy Shyrkov created JCR-3560:
-----------------------------------

             Summary: CachingHierarchyManager.stateDiscarded() call to provider.hasItemState(discarded.getId())
                 Key: JCR-3560
                 URL: https://issues.apache.org/jira/browse/JCR-3560
             Project: Jackrabbit Content Repository
          Issue Type: Bug
          Components: jackrabbit-core
    Affects Versions: 2.6, 2.5.3, 2.4.3, 2.2.13
            Reporter: Sergiy Shyrkov
            Priority: Minor


As a follow up of the discussion in users mailing list: http://markmail.org/thread/w4ubczmddkqdzoac

Hello guys,

I would need your help in understanding the code in the CachingHierarchyManager.stateDiscarded()
method (Jackrabbit 2.2.4). A short background: I am working on a tool to purge orphaned version
history from the repository (version history for nodes, which are no longer present in the
repository). The version store is quite large (the row count in the version bundle table is
around 12 000 000 entries). When profiling the tool execution I see in the snapshot that in
the CachingHierarchyManager.stateDiscarded() method the provider.hasItemState(discarded.getId())
is called. In my case this happens quite often and the call provider.hasItemState() goes into
the DB and loads the bundle. The things is that the item is no longer present and the provider.hasItemState()
evaluates to false.

The call in my case is coming from the org.apache.jackrabbit.core.state.ChangeLog.persisted()
where we have the following lines:

... for (ItemState state : deletedStates()) { state.setStatus(ItemState.STATUS_EXISTING_REMOVED);
state.notifyStateDestroyed(); state.discard(); } ...

The state.discard() calls the notifyStateDiscarded();

Is it really needed here after we have already called state.notifyStateDestroyed()?

If yes, is there any way we can optimize the check in the CachingHierarchyManager.stateDiscarded()
to not call provider.hasItemState() in some cases? Perhaps check for discarded.getStatus()
!= ItemState.STATUS_EXISTING_REMOVED first or similar?

I am attaching the profiler snapshot (CachingHierarchyManager-stateDiscarded.png). Also provided
here: http://img580.imageshack.us/img580/7179/cachinghierarchymanager.png
And just in case the image won't get through the mailing list, here is a text representation
of the method call trace: 

org.apache.jackrabbit.core.state.ChangeLog.persisted()
 - org.apache.jackrabbit.core.state.ItemState.discard()
  - org.apache.jackrabbit.core.state.ItemState.notifyStateDiscarded()
   - org.apache.jackrabbit.core.state.SharedItemStateManager.stateDiscarded(ItemState)
    - org.apache.jackrabbit.core.state.StateChangeDispatcher.notifyStateDiscarded(ItemState)
     - org.apache.jackrabbit.core.state.SharedItemStateManager.stateDiscarded(ItemState)
      - org.apache.jackrabbit.core.state.StateChangeDispatcher.notifyStateDiscarded(ItemState)
       - org.apache.jackrabbit.core.CachingHierarchyManager.stateDiscarded(ItemState)
        - org.apache.jackrabbit.core.state.SharedItemStateManager.hasItemState(ItemId)
         - org.apache.jackrabbit.core.state.SharedItemStateManager.hasNonVirtualItemState(ItemId)
          - org.apache.jackrabbit.core.persistence.bundle.AbstractBundlePersistenceManager.exists(PropertyId)
           - org.apache.jackrabbit.core.persistence.bundle.AbstractBundlePersistenceManager.getBundle(NodeId)
            - org.apache.jackrabbit.core.persistence.pool.BundleDbPersistenceManager.loadBundle(NodeId)
             - org.apache.jackrabbit.core.util.db.ConnectionHelper.exec(String, Object[],
boolean, int)


Thank you in advance for any hints!
Sergiy Shyrkov

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message