[jira] [Commented] (JCR-3622) Deadlock when accessing to jackrabbit

["Claus Köll (JIRA)" <ji...@apache.org>]

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

Claus Köll commented on JCR-3622:
---------------------------------

Hi Petr,

If its possible you should upgrade to the latest stable version of jackrabbit. Indeed there were more issues with deadlocks inside jackrabbit in older versions.

greets
claus
                
> Deadlock when accessing to jackrabbit
> -------------------------------------
>
>                 Key: JCR-3622
>                 URL: https://issues.apache.org/jira/browse/JCR-3622
>             Project: Jackrabbit Content Repository
>          Issue Type: Bug
>          Components: jackrabbit-core
>    Affects Versions: 1.6
>         Environment: RHEL, JBoss 5.1, Java 7
>            Reporter: Petr Sochurek
>         Attachments: thread-dumps-1.txt
>
>
> Dear Apache Community,
> We are using Jackrabbit 1.6.0 as a document store for our app running on JBoss5.1.
> Since we started to use Jackrabbit more intensively, deadlocks in Jackrabbit internals occurr.
> Something inside is locked (for unknown reason) which lead to infinite blocking all threads which want to use Jackrabbit (when logging to jcr session, commiting etc)
> On production environment the deadlock occurs every day and only JBoss restart helps.
> Unfortunately I have no scenario to reproduce problem. 
> The thread dump which shows dependencies between blocking threads is enclosed.    
> I found similar bug solved in JCR-2554 but I am not sure whether relates to the same problem.
> Could you please confirm that this is a JCR bug. And if so, is it repaired in 1.6.5 version or is there any known workaround?
> Thank you very much,
> PS
> E.g. stack trace of blocked thread:
> {code}
>  Thread: pool-185-thread-1 : priority:5, demon:false, threadId:477, threadState:WAITING
>                 - waiting on <0x30c571db> (a EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$ReaderLock)
>                 java.lang.Object.wait(Native Method)
>                 java.lang.Object.wait(Object.java:503)
>                 EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$ReaderLock.acquire(WriterPreferenceReadWriteLock.java:163)
>                 org.apache.jackrabbit.core.state.DefaultISMLocking$ReadLockImpl.(DefaultISMLocking.java:84)
>                 org.apache.jackrabbit.core.state.DefaultISMLocking$ReadLockImpl.(DefaultISMLocking.java:78)
>                 org.apache.jackrabbit.core.state.DefaultISMLocking.acquireReadLock(DefaultISMLocking.java:44)
>                 org.apache.jackrabbit.core.state.SharedItemStateManager.acquireReadLock(SharedItemStateManager.java:1432)
>                 org.apache.jackrabbit.core.state.SharedItemStateManager.getItemState(SharedItemStateManager.java:253)
>                 org.apache.jackrabbit.core.state.LocalItemStateManager.getNodeState(LocalItemStateManager.java:107)
>                 org.apache.jackrabbit.core.state.LocalItemStateManager.getItemState(LocalItemStateManager.java:172)
>                 - locked <0x1d0c34b> (a org.apache.jackrabbit.core.state.XAItemStateManager)
>                 org.apache.jackrabbit.core.state.XAItemStateManager.getItemState(XAItemStateManager.java:260)
>                 org.apache.jackrabbit.core.version.XAVersionManager.(XAVersionManager.java:115)
>                 org.apache.jackrabbit.core.XASessionImpl.createVersionManager(XASessionImpl.java:175)
>                 org.apache.jackrabbit.core.SessionImpl.(SessionImpl.java:303)
>                 org.apache.jackrabbit.core.SessionImpl.(SessionImpl.java:271)
>                 org.apache.jackrabbit.core.XASessionImpl.(XASessionImpl.java:105)
>                 org.apache.jackrabbit.core.RepositoryImpl.createSessionInstance(RepositoryImpl.java:1517)
>                 org.apache.jackrabbit.core.RepositoryImpl.createSession(RepositoryImpl.java:964)
>                 org.apache.jackrabbit.core.RepositoryImpl.login(RepositoryImpl.java:1395)
>                 org.apache.jackrabbit.jca.JCAManagedConnectionFactory.openSession(JCAManagedConnectionFactory.java:140)
>                 org.apache.jackrabbit.jca.JCAManagedConnectionFactory.createManagedConnection(JCAManagedConnectionFactory.java:176)
>                 org.apache.jackrabbit.jca.JCAManagedConnectionFactory.createManagedConnection(JCAManagedConnectionFactory.java:168)
>                 org.jboss.resource.connectionmanager.InternalManagedConnectionPool.createConnectionEventListener(InternalManagedConnectionPool.java:633)
>                 org.jboss.resource.connectionmanager.InternalManagedConnectionPool.getConnection(InternalManagedConnectionPool.java:267)
>                 org.jboss.resource.connectionmanager.JBossManagedConnectionPool$BasePool.getConnection(JBossManagedConnectionPool.java:622)
>                 org.jboss.resource.connectionmanager.BaseConnectionManager2.getManagedConnection(BaseConnectionManager2.java:404)
>                 org.jboss.resource.connectionmanager.TxConnectionManager.getManagedConnection(TxConnectionManager.java:381)
>                 org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:496)
>                 org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:941)
>                 org.apache.jackrabbit.jca.JCARepositoryHandle.login(JCARepositoryHandle.java:98)
>                 org.apache.jackrabbit.jca.JCARepositoryHandle.login(JCARepositoryHandle.java:89)
>                 org.apache.jackrabbit.jca.JCARepositoryHandle.login(JCARepositoryHandle.java:73)
> {code}

--
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