[
https://issues.apache.org/jira/browse/JCR-3622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13715028#comment-13715028
]
Petr Sochurek commented on JCR-3622:
------------------------------------
Hello Claus,
thank you for your comment.
By comparing the SVN versions 1.6.0 and 1.6.5 I see significant changes you did
in DefaultISMLocking.
Please, can you advise me how to simulate the deadlock (thread lock
contention)?
We have stored the document content in the mysql, and have configured indexes
on file system, we do not use performance cluster.
I have tried to simulate deadlock by simple stress test (doing lots of
concurrent reads and writes) - but no deadlock occurrs after a week :(.
Do you think is it a good way? Maybe is it possible that the deadlock occurrs
during some system problem, e.g. no database connection, or out of memory?
I checked locally that 1.6.5 is functional, but I would like to check that
1.6.5 really solves the deadlock issue before using it on production.
Greets,
Petr
> 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
