Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Message-ID: <642572341.1254908611272.JavaMail.jira@brutus>
Date: Wed, 7 Oct 2009 02:43:31 -0700 (PDT)
From: "Stefan Guggisberg (JIRA)" <jira@apache.org>
To: dev@jackrabbit.apache.org
Subject: [jira] Commented: (JCR-2345) Many threads are blocked trying to get
 lock:
 org/apache/jackrabbit/core/persistence/bundle/OraclePersistenceManager@0x2b71b2c979c0[fat
 lock]
In-Reply-To: <1886401224.1254654656239.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/JCR-2345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12762968#action_12762968 ] 

Stefan Guggisberg commented on JCR-2345:
----------------------------------------

> I have looked through the code of AbstractBundlePersistenceManager.java and it seems many methods of it are sycnronised when variable _bundles_ is accessed. That variable is of type BundleCache. Will it not be possible to move synronisation tasks directly to that class? Inside that as I see it uses simple LinkedMap, but what if it used the ConcurrentMap instead? Will then the syncronisation be less intensive?

i am not too familiar with the bundle db pm implementation. maybe it's worth a try. patches are welcome ;) 

> Many threads are blocked trying to get lock: org/apache/jackrabbit/core/persistence/bundle/OraclePersistenceManager@0x2b71b2c979c0[fat lock]
> --------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JCR-2345
>                 URL: https://issues.apache.org/jira/browse/JCR-2345
>             Project: Jackrabbit Content Repository
>          Issue Type: Bug
>          Components: jackrabbit-core, JCR 1.0.1
>    Affects Versions: 1.5.5
>         Environment: HP Unix
>            Reporter: Andrey Adamovich
>         Attachments: dump1.txt, dump2.txt, dump3.txt
>
>
> We implemented a multi-threaded export functionlity for our JR repository, but it turns out that intended parallel behavior can't be achieved becuase most of the threads seemed to be waiting for OraclePersistenceManager. 
> This is the stack trace for most of the waiting threads:
>     -- Blocked trying to get lock: org/apache/jackrabbit/core/persistence/bundle/OraclePersistenceManager@0x2b71b2c979c0[fat lock]
>     at jrockit/vm/Threads.waitForUnblockSignal()V(Native Method)
>     at jrockit/vm/Locks.fatLockBlockOrSpin(Locks.java:1675)[optimized]
>     at jrockit/vm/Locks.lockFat(Locks.java:1776)[optimized]
>     at jrockit/vm/Locks.monitorEnterSecondStageHard(Locks.java:1312)[optimized]
>     at jrockit/vm/Locks.monitorEnterSecondStage(Locks.java:1259)[optimized]
>     at org/apache/jackrabbit/core/persistence/bundle/AbstractBundlePersistenceManager.exists(AbstractBundlePersistenceManager.java:506)[optimized]
>     at org/apache/jackrabbit/core/state/SharedItemStateManager.hasNonVirtualItemState(SharedItemStateManager.java:1343)[inlined]
>     at org/apache/jackrabbit/core/state/SharedItemStateManager.hasItemState(SharedItemStateManager.java:297)[optimized]
>     at org/apache/jackrabbit/core/state/XAItemStateManager.hasItemState(XAItemStateManager.java:295)[optimized]
>     at org/apache/jackrabbit/core/state/SessionItemStateManager.getItemState(SessionItemStateManager.java:181)[optimized]
>     at org/apache/jackrabbit/core/ItemManager.getItemData(ItemManager.java:282)[inlined]
>     at org/apache/jackrabbit/core/ItemManager.getItemData(ItemManager.java:249)[inlined]
>     at org/apache/jackrabbit/core/ItemManager.getNode(ItemManager.java:513)[inlined]
>     at org/apache/jackrabbit/core/LazyItemIterator.prefetchNext(LazyItemIterator.java:109)[inlined]
>     at org/apache/jackrabbit/core/LazyItemIterator.next(LazyItemIterator.java:230)[inlined]
>     at org/apache/jackrabbit/core/LazyItemIterator.nextNode(LazyItemIterator.java:137)[optimized]
>     ^-- Holding lock: org/apache/jackrabbit/core/ItemManager@0x2b71ec068f58[thin lock]
>     at org/apache/jackrabbit/commons/xml/Exporter.exportNodes(Exporter.java:212)[optimized]
>     at org/apache/jackrabbit/commons/xml/DocumentViewExporter.exportNode(DocumentViewExporter.java:77)[inlined]
>     at org/apache/jackrabbit/commons/xml/Exporter.exportNode(Exporter.java:294)[inlined]
>     at org/apache/jackrabbit/commons/xml/Exporter.export(Exporter.java:143)[optimized]
>     at org/apache/jackrabbit/commons/AbstractSession.export(AbstractSession.java:462)[inlined]
>     at org/apache/jackrabbit/commons/AbstractSession.exportDocumentView(AbstractSession.java:236)[inlined]
>     at org/apache/jackrabbit/commons/AbstractSession.exportDocumentView(AbstractSession.java:281)[optimized]
>     ^-- Holding lock: org/apache/jackrabbit/core/XASessionImpl@0x2b71ec068950[thin lock]
> This is the stack trace for blocking thread:
>     at jrockit/net/SocketNativeIO.readBytesPinned(Ljava/io/FileDescriptor;[BIII)I(Native Method)
>     at jrockit/net/SocketNativeIO.socketRead(SocketNativeIO.java:46)[optimized]
>     at java/net/SocketInputStream.socketRead0(Ljava/io/FileDescriptor;[BIII)I(SocketInputStream.java)[inlined]
>     at java/net/SocketInputStream.read(SocketInputStream.java:129)[optimized]
>     at oracle/net/ns/Packet.receive()V(Unknown Source)[inlined]
>     at oracle/net/ns/DataPacket.receive()V(Unknown Source)[optimized]
>     at oracle/net/ns/NetInputStream.getNextPacket()V(Unknown Source)[optimized]
>     at oracle/net/ns/NetInputStream.read([BII)I(Unknown Source)[inlined]
>     at oracle/net/ns/NetInputStream.read([B)I(Unknown Source)[inlined]
>     at oracle/net/ns/NetInputStream.read()I(Unknown Source)[optimized]
>     at oracle/jdbc/driver/T4CMAREngine.unmarshalUB1(T4CMAREngine.java:1104)[inlined]
>     at oracle/jdbc/driver/T4CMAREngine.unmarshalSB1(T4CMAREngine.java:1075)[inlined]
>     at oracle/jdbc/driver/T4C8TTILob.receiveReply(T4C8TTILob.java:872)[optimized]
>     at oracle/jdbc/driver/T4C8TTILob.getChunkSize(T4C8TTILob.java:329)[inlined]
>     at oracle/jdbc/driver/T4CConnection.getChunkSize(T4CConnection.java:2026)[optimized]
>     ^-- Holding lock: oracle/jdbc/driver/T4CConnection@0x2b71b2ce0650[thin lock]
>     at oracle/sql/BLOB.getChunkSize(BLOB.java:389)[inlined]
>     at oracle/sql/BLOB.getBufferSize(BLOB.java:410)[inlined]
>     at oracle/sql/BLOB.getBinaryStream(BLOB.java:229)[optimized]
>     at org/apache/jackrabbit/core/persistence/bundle/BundleDbPersistenceManager.getBytes(BundleDbPersistenceManager.java:1110)[inlined]
>     at org/apache/jackrabbit/core/persistence/bundle/BundleDbPersistenceManager.loadBundle(BundleDbPersistenceManager.java:1142)[inlined]
>     at org/apache/jackrabbit/core/persistence/bundle/BundleDbPersistenceManager.loadBundle(BundleDbPersistenceManager.java:1094)[inlined]
>     at org/apache/jackrabbit/core/persistence/bundle/AbstractBundlePersistenceManager.getBundle(AbstractBundlePersistenceManager.java:701)[inlined]
>     at org/apache/jackrabbit/core/persistence/bundle/AbstractBundlePersistenceManager.exists(AbstractBundlePersistenceManager.java:506)[optimized]
>     ^-- Holding lock: org/apache/jackrabbit/core/persistence/bundle/OraclePersistenceManager@0x2b71b2c979c0[fat lock]
>     at org/apache/jackrabbit/core/state/SharedItemStateManager.hasNonVirtualItemState(SharedItemStateManager.java:1343)[inlined]
>     at org/apache/jackrabbit/core/state/SharedItemStateManager.hasItemState(SharedItemStateManager.java:297)[optimized]
>     at org/apache/jackrabbit/core/state/XAItemStateManager.hasItemState(XAItemStateManager.java:295)[optimized]
>     at org/apache/jackrabbit/core/state/SessionItemStateManager.getItemState(SessionItemStateManager.java:181)[optimized]
>     at org/apache/jackrabbit/core/ItemManager.getItemData(ItemManager.java:282)[inlined]
>     at org/apache/jackrabbit/core/ItemManager.getItemData(ItemManager.java:249)[inlined]
>     at org/apache/jackrabbit/core/ItemManager.getNode(ItemManager.java:513)[inlined]
>     at org/apache/jackrabbit/core/LazyItemIterator.prefetchNext(LazyItemIterator.java:109)[inlined]
>     at org/apache/jackrabbit/core/LazyItemIterator.next(LazyItemIterator.java:230)[inlined]
>     at org/apache/jackrabbit/core/LazyItemIterator.nextNode(LazyItemIterator.java:137)[optimized]
>     ^-- Holding lock: org/apache/jackrabbit/core/ItemManager@0x2b71dcf8c668[thin lock]
>     at org/apache/jackrabbit/commons/xml/Exporter.exportNodes(Exporter.java:212)[optimized]
>     at org/apache/jackrabbit/commons/xml/DocumentViewExporter.exportNode(DocumentViewExporter.java:77)[inlined]
>     at org/apache/jackrabbit/commons/xml/Exporter.exportNode(Exporter.java:294)[inlined]
>     at org/apache/jackrabbit/commons/xml/Exporter.export(Exporter.java:143)[optimized]
>     at org/apache/jackrabbit/commons/AbstractSession.export(AbstractSession.java:462)[inlined]
>     at org/apache/jackrabbit/commons/AbstractSession.exportDocumentView(AbstractSession.java:236)[inlined]
>     at org/apache/jackrabbit/commons/AbstractSession.exportDocumentView(AbstractSession.java:281)[optimized]
>     ^-- Holding lock: org/apache/jackrabbit/core/XASessionImpl@0x2b71dcf8c3c0[thin lock]
> Oracle database performfs as usual. So, I doubt that it is an Oracle problem. In any case is there any way to avoid other threads blocking each other while performing read operations from PM?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.