Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Date: Tue, 26 Mar 2013 12:07:15 +0000 (UTC)
From: "Mladen Turk (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Message-ID: <JIRA.12637750.1363696083834.55435.1364299635259@arcas>
In-Reply-To: <JIRA.12637750.1363696083834@arcas>
References: <JIRA.12637750.1363696083834@arcas>
Subject: [jira] [Resolved] (DAEMON-288) Hang while stopping procrun service
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


     [ https://issues.apache.org/jira/browse/DAEMON-288?page=3Dcom.atlassia=
n.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mladen Turk resolved DAEMON-288.
--------------------------------

       Resolution: Fixed
    Fix Version/s: 1.0.15

Patch applied. Thanks!
               =20
> Hang while stopping procrun service
> -----------------------------------
>
>                 Key: DAEMON-288
>                 URL: https://issues.apache.org/jira/browse/DAEMON-288
>             Project: Commons Daemon
>          Issue Type: Bug
>          Components: Procrun
>    Affects Versions: 1.0.13
>         Environment: Windows 7 64 bit
>            Reporter: Mike Miller
>             Fix For: 1.0.15
>
>         Attachments: prunsrv.c.patch
>
>
> There is a hang of the procrun service while it is attempting to stop.  I=
t is not easy to reproduce ( 30%-5% depending on pc ).  Using a debugging t=
o analyze the hang, both the serviceMain() and serviceStop() threads appear=
 to have run and exited.  I can tell this from the state of the global vari=
ables like gSargs and gShutdownEvents.  Looking at the code, both are calli=
ng reportServiceStatus( SERVICE_STOPPED...).  Typically when either one rep=
orts SERVICE_STOPPED, the main thread unblocks and the process terminates. =
 This often occurs without both threads running to completion.  I think thi=
s is a race condition caused by the reportServiceStatus() usage.  The MSDN =
documentation for SetServiceStatus() states to only call SetServiceStatus()=
 with SERVICE_STOPPED after all cleanup has occurred and to only call it on=
ce.  It appears that procrun has a race condition where 2 threads will both=
 attempt to report SERVICE_STOPPED and will likely report this while the ot=
her thread is still running.  I believe this is the root cause of why the S=
ervice Control Manager sometimes is unable to stop the service.  =20
> =20
> As a potential solution, I modified serviceStop() to not call reportServi=
ceStatus(SERVICE_STOPPED...) and to move the SetEvent( gShutdownEvent) to t=
he end of the method.  This change allows the thread running the  serviceSt=
op() to complete.  Now the only method reporting stopped is when serviceMai=
n() exits.  With this refactoring to only report SERVICE_STOPPED once (per =
MSDN) the hang has not been reproducible. =20

--
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