jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Reutegger <mreut...@adobe.com>
Subject RE: CachingHierarchyManager.stateDiscarded() call to provider.hasItemState(discarded.getId())
Date Thu, 04 Apr 2013 11:37:15 GMT
Hi,

we hit a similar problem a while ago with session logout:
https://issues.apache.org/jira/browse/JCR-2231

might be worth creating a JIRA issue for your case.

regards
 marcel

> -----Original Message-----
> From: Sergiy Shyrkov [mailto:my.public.mailing@gmail.com]
> Sent: Mittwoch, 3. April 2013 23:52
> To: users@jackrabbit.apache.org
> Subject: CachingHierarchyManager.stateDiscarded() call to
> provider.hasItemState(discarded.getId())
> 
> 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) 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(It
> emState)
>      -
> org.apache.jackrabbit.core.state.StateChangeDispatcher.notifyStateDiscarde
> d(ItemState)
>       -
> org.apache.jackrabbit.core.state.SharedItemStateManager.stateDiscarded(It
> emState)
>        -
> org.apache.jackrabbit.core.state.StateChangeDispatcher.notifyStateDiscarde
> d(ItemState)
>         -
> org.apache.jackrabbit.core.CachingHierarchyManager.stateDiscarded(ItemSt
> ate)
>          -
> org.apache.jackrabbit.core.state.SharedItemStateManager.hasItemState(Ite
> mId)
>           -
> org.apache.jackrabbit.core.state.SharedItemStateManager.hasNonVirtualIte
> mState(ItemId)
>            -
> org.apache.jackrabbit.core.persistence.bundle.AbstractBundlePersistenceM
> anager.exists(PropertyId)
>             -
> org.apache.jackrabbit.core.persistence.bundle.AbstractBundlePersistenceM
> anager.getBundle(NodeId)
>              -
> org.apache.jackrabbit.core.persistence.pool.BundleDbPersistenceManager.l
> oadBundle(NodeId)
>               -
> org.apache.jackrabbit.core.util.db.ConnectionHelper.exec(String,
> Object[], boolean, int)
> 
> 
> Thank you in advance for any hints!
> Sergiy Shyrkov


Mime
View raw message