jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dürig (JIRA) <j...@apache.org>
Subject [jira] [Commented] (OAK-279) ChangeProcessor getting stuck while shutdown
Date Mon, 27 Aug 2012 13:56:07 GMT

    [ https://issues.apache.org/jira/browse/OAK-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13442419#comment-13442419

Michael Dürig commented on OAK-279:

Thanks for finding this. This seems to be broken in other ways also. I'll have a look. 
However calling {{stopped.countDown()}} only when {{stopping}} is {{true}} is also incorrect:
this introduces a race which might cause a call on {{stop()}} to block forever.

> ChangeProcessor getting stuck while shutdown
> --------------------------------------------
>                 Key: OAK-279
>                 URL: https://issues.apache.org/jira/browse/OAK-279
>             Project: Jackrabbit Oak
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 0.5
>            Reporter: Chetan Mehrotra
>            Assignee: Michael Dürig
>            Priority: Minor
>         Attachments: OAK-279.patch, stacktrace.txt
> o.a.j.oak.jcr.observation.ChangeProcessor is preventing system shutdown
> {noformat}
> "FelixStartLevel" daemon prio=10 tid=0x00007fbda846e000 nid=0x78d5 waiting on condition
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0x00000000b8931378> (a java.util.concurrent.CountDownLatch$Sync)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:156)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:811)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:969)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1281)
> 	at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:207)
> 	at org.apache.jackrabbit.oak.jcr.observation.ChangeProcessor.stop(ChangeProcessor.java:76)
> 	- locked <0x00000000b89312d0> (a org.apache.jackrabbit.oak.jcr.observation.ChangeProcessor)
> 	at org.apache.jackrabbit.oak.jcr.observation.ObservationManagerImpl.removeEventListener(ObservationManagerImpl.java:87)
> 	- locked <0x00000000b8931210> (a org.apache.jackrabbit.oak.jcr.observation.ObservationManagerImpl)
> 	at com.adobe.granite.workflow.core.eventsupport.JcrToWorkflowEventService.deactivate(JcrToWorkflowEventService.java:139)
> {noformat}
> Complete thread dump would be attached.
> Looking at ChangeProcessor.stop [1] method it appears that latch would not be cleared
if an exception is thrown in the run() method and running variable remains set to true. 
> One possible solution is perform {{stopped.countDown();}} in a finally block in case
{{stopping}} is set to true. Further it appears that countDown should only be done in case
stopping is true. Currently it is performed for every run
> [1] https://github.com/apache/jackrabbit-oak/blob/trunk/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/observation/ChangeProcessor.java#L72

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

View raw message