Mailing-List: contact oak-dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: oak-dev@jackrabbit.apache.org
Date: Tue, 28 Aug 2012 00:56:07 +1100 (NCT)
From: =?utf-8?Q?Michael_D=C3=BCrig_=28JIRA=29?= <jira@apache.org>
To: oak-dev@jackrabbit.apache.org
Message-ID: <840345982.1216.1346075767553.JavaMail.jiratomcat@arcas>
In-Reply-To: <86757704.5145.1345915319710.JavaMail.jiratomcat@arcas>
Subject: [jira] [Commented] (OAK-279) ChangeProcessor getting stuck while
 shutdown
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/OAK-279?page=3Dcom.atlassian.ji=
ra.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D1344241=
9#comment-13442419 ]=20

Michael D=C3=BCrig commented on OAK-279:
-----------------------------------

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

               =20
> 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=C3=BCrig
>            Priority: Minor
>         Attachments: OAK-279.patch, stacktrace.txt
>
>
> o.a.j.oak.jcr.observation.ChangeProcessor is preventing system shutdown
> {noformat}
> "FelixStartLevel" daemon prio=3D10 tid=3D0x00007fbda846e000 nid=3D0x78d5 =
waiting on condition [0x00007fbda41ce000]
>    java.lang.Thread.State: WAITING (parking)
> =09at sun.misc.Unsafe.park(Native Method)
> =09- parking to wait for  <0x00000000b8931378> (a java.util.concurrent.Co=
untDownLatch$Sync)
> =09at java.util.concurrent.locks.LockSupport.park(LockSupport.java:156)
> =09at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckI=
nterrupt(AbstractQueuedSynchronizer.java:811)
> =09at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShar=
edInterruptibly(AbstractQueuedSynchronizer.java:969)
> =09at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared=
Interruptibly(AbstractQueuedSynchronizer.java:1281)
> =09at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:207)
> =09at org.apache.jackrabbit.oak.jcr.observation.ChangeProcessor.stop(Chan=
geProcessor.java:76)
> =09- locked <0x00000000b89312d0> (a org.apache.jackrabbit.oak.jcr.observa=
tion.ChangeProcessor)
> =09at org.apache.jackrabbit.oak.jcr.observation.ObservationManagerImpl.re=
moveEventListener(ObservationManagerImpl.java:87)
> =09- locked <0x00000000b8931210> (a org.apache.jackrabbit.oak.jcr.observa=
tion.ObservationManagerImpl)
> =09at com.adobe.granite.workflow.core.eventsupport.JcrToWorkflowEventServ=
ice.deactivate(JcrToWorkflowEventService.java:139)
> {noformat}
> Complete thread dump would be attached.
> Looking at ChangeProcessor.stop [1] method it appears that latch would no=
t be cleared if an exception is thrown in the run() method and running vari=
able remains set to true.=20
> One possible solution is perform {{stopped.countDown();}} in a finally bl=
ock 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 administrato=
rs
For more information on JIRA, see: http://www.atlassian.com/software/jira