jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Abley" <james.ab...@gmail.com>
Subject Contention for AbstractBundlePersistenceManager
Date Fri, 13 Jun 2008 10:26:13 GMT
Hi,

(This may be better suited to the dev list, but trying here first).

We have a web application using Jackrabbit 1.4 vanilla within
Weblogic, pointing at an Oracle database. We're using the
Oracel9PersistenceManager as the PersistenceManager.

We're profiling the application and seeing a lot of contention on the
Persistence Manager itself. Lots of items like this in the thread
dump:

"[ACTIVE] ExecuteThread: '9' for queue: 'weblogic.kernel.Default
(self-tuning)'" id=95 idx=0x174 tid=20645 prio=5 alive, in native,
blocked, daemon
    -- Blocked trying to get lock:
org/apache/jackrabbit/core/persistence/bundle/Oracle9PersistenceManager@
0x9c61388[thin lock]
    at pthread_cond_wait@@GLIBC_2.3.2+170(:0)@0x37eaa08a7a
    at vmtWaitUntilNotSoftSuspended+66(:0)@0x2a955f39ea
    at tsCheckTransitToJava+31(:0)@0x2a955f3aad
    at jrockit/vm/Threads.sleep(I)V(Native Method)
    at jrockit/vm/Locks.waitForThinRelease(Locks.java:1233)[optimized]
    at
jrockit/vm/Locks.monitorEnterSecondStage(Locks.java:1307)[optimized]
    at
org/apache/jackrabbit/core/persistence/bundle/AbstractBundlePersistenceM
anager.exists(AbstractBundlePersistenceManager.java:487)[optimized]
    at
org/apache/jackrabbit/core/state/SharedItemStateManager.hasNonVirtualIte
mState(SharedItemStateManager.java:1110)[inlined]
    at
org/apache/jackrabbit/core/state/SharedItemStateManager.getItemState(Sha
redItemStateManager.java:247)[optimized]
    at
org/apache/jackrabbit/core/state/LocalItemStateManager.getPropertyState(
LocalItemStateManager.java:118)[inlined]
    at
org/apache/jackrabbit/core/state/LocalItemStateManager.getItemState(Loca
lItemStateManager.java:150)[inlined]
    at
org/apache/jackrabbit/core/state/XAItemStateManager.getItemState(XAItemS
tateManager.java:226)[optimized]
    ^-- Holding lock:
org/apache/jackrabbit/core/state/XAItemStateManager@0xcff9810[thin lock]
    at
org/apache/jackrabbit/core/state/SessionItemStateManager.getItemState(Se
ssionItemStateManager.java:175)[optimized]
    at
org/apache/jackrabbit/core/ItemManager.createItemInstance(ItemManager.ja
va:564)[inlined]
    at
org/apache/jackrabbit/core/ItemManager.getItem(ItemManager.java:395)[inl
ined]
    at
org/apache/jackrabbit/core/LazyItemIterator.prefetchNext(LazyItemIterato
r.java:90)[inlined]
    at
org/apache/jackrabbit/core/LazyItemIterator.next(LazyItemIterator.java:2
03)[optimized]
    ^-- Holding lock:
org/apache/jackrabbit/core/ItemManager@0xcff95e0[thin lock]

The most we've seen is 59 threads blocked trying to acquire this lock.
Obviously that varies depending on how many concurrent requests we're
handling and how lucky (sic) we are when the thread dump happens.

Looking at the code, the actual method that is blocking is in
AbstractBundlePersistenceManager; specifically:

    /**
     * {@inheritDoc}
     *
     * Checks the existence via the appropriate NodePropBundle.
     */
    public synchronized boolean exists(NodeId id) throws ItemStateException {
        // anticipating a load followed by a exists
        return getBundle(id) != null;
    }

This is synchronized at a method level. I've tried simulating
getBundle taking a long time; e.g. reading a large BLOB back from the
database; by setting a breakpoint lower in the call stack and the
effect obviously is that all other requests are blocked until the
database call comes back, then the threads can start competing to
acquire the PersistenceManager lock again.

I'm not very familiar with the code, otherwise I'd understand that
this might be an obviously stupid question, but might it be possible
to use a different synchronization strategy? The current
implementation seems to damage scalability. Could anyone comment on
the reasons for wishing to synchronize on the method at that point? If
I can understand what data structures are being protected, then it
might be possible to suggest maybe using a different strategy (I would
suggest using an explicit lock object anyway; rather than using the
synchronized keyword on the method; c.f. Java Puzzlers (Bloch, Gafter)
www.javapuzzlers.com ). Lock-striping might be a possibility, etc.

Cheers,

James

Mime
View raw message