[
https://issues.apache.org/jira/browse/JCR-2232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Klimetschek resolved JCR-2232.
----------------------------------------
Resolution: Won't Fix
As noted in JCR-990 and http://jira.springframework.org/browse/MOD-372, the app
server should call TransientRepository.shutdown() and not
RepositoryImpl.shutdown() directly (in
com.liferay.portal.jcr.jackrabbit.JCRFactoryImpl.shutdown(JCRFactoryImpl.java:164)).
> 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.
