[
https://issues.apache.org/jira/browse/JCR-2232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12737234#action_12737234
]
Alexander Klimetschek commented on JCR-2232:
--------------------------------------------
> Is it really a viable solution to move knowledge about the repository
> implementation (whether it is TransientRepository
> or RepositoryImpl) inside the client?
Certain things such as creation and shutdown of a Repository are not defined by
the JCR 1.0 spec; also, the TransientRepository is the instance that is created
by the client, so he definitely has knowledge about it and its shutdown()
method.
> shutdown deadlock
> -----------------
>
> Key: JCR-2232
> URL: https://issues.apache.org/jira/browse/JCR-2232
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: clustering, jackrabbit-core
> Affects Versions: 1.5.6
> Environment: JDK 1.6.0_13, JBoss, Liferay 5.2.2, Oracle 10g
> Reporter: Timo Pick
> Attachments: jboss-does-not-stop-dump.txt, repository.xml
>
>
> Enviroment: I'm using Liferay in a clustered environment with two JBoss
> nodes. Liferay uses Jackrabbit to save documents and attachments. Jackrabbit
> uses an Oracle10g database as filesystem, repository and workspace. (see
> repository.xml)
> Problem: shutting down jboss leads to a deadlock in the
> RepositoryImpl.shutdown() method as it tries to acquire a ReadWriteLock.
> RepositoryImpl calls shutdown() which tells all the Sessions to logout(). The
> callback method TransientRepository.loggedOut() is called. This method calls
> RepositoryImpl.shutdown() again (!!!). This is where the deadlock occurs. The
> lock can not be acquired again as it already is acquired by the first call. I
> have appended the java stacktrace (see jboss-does-not-stop.txt)
> Possible Solution: prevent TransientSession.loggedOut() from calling
> RepositoryImpl.shutdown()
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
