Hi coders,
I have a service that does alot of data copying to the database and when the
service is stopped or the machine is shutting down it commits the data (in
addition to other things) and makes sure it exists gracefully (this could
take upto 5-6 mins).

I tried increasing
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\WaitToKillServiceTimeout
to 5 mins (300000) on a test service that sleeps for 4 mins when
OnStop/Shutdown is called but that didnt work, I also tried using
RequestAdditionalTime(290000) but again that didnt work.
In all my test cases the SCM returns after 2 mins with Error 1053 (timeout)
and marks the service as stopping but never waits the time specified in
RequestAdditionalTime or the WaitToKillServiceTimeout.
ServiceBase.CanShutdown and ServiceBase.CanStop are both set to true

In the case of the OnStop the SCM doesnt kill the EXE and service completes
its task but if it is a Shutdown the exe gets killed before the time elapses.

Am i missing somthing, are these settings being overwritten somewhere else?
Note that
Thanks alot.
-Ash

Ash,

If I am not mistaken, Windows ultimately will disregard requests for
more time after 30 seconds (I could be wrong on the time).

Frankly, it's not a good idea to keep the machine running for another
5-6 minutes if a user requested a shutdown. Is there any way that you can
write the data while the service is running, instead of dumping it all in
the end?

Hope this helps.

--
- Nicholas Paldino [.NET/C# MVP]
- (E-Mail Removed)

"Ash" <(E-Mail Removed)> wrote in message
news:0A0653A2-0254-4A8C-A211-(E-Mail Removed)...
> Hi coders,
> I have a service that does alot of data copying to the database and when
> the
> service is stopped or the machine is shutting down it commits the data (in
> addition to other things) and makes sure it exists gracefully (this could
> take upto 5-6 mins).
>
> I tried increasing
> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\WaitToKillServiceTimeout
> to 5 mins (300000) on a test service that sleeps for 4 mins when
> OnStop/Shutdown is called but that didnt work, I also tried using
> RequestAdditionalTime(290000) but again that didnt work.
> In all my test cases the SCM returns after 2 mins with Error 1053
> (timeout)
> and marks the service as stopping but never waits the time specified in
> RequestAdditionalTime or the WaitToKillServiceTimeout.
> ServiceBase.CanShutdown and ServiceBase.CanStop are both set to true
>
> In the case of the OnStop the SCM doesnt kill the EXE and service
> completes
> its task but if it is a Shutdown the exe gets killed before the time
> elapses.
>
> Am i missing somthing, are these settings being overwritten somewhere
> else?
> Note that
> Thanks alot.
> -Ash

Nicholas,
Thank you for the quick reply. Unfortunatly this is not an option because
the process is not writing the data directly. Instead my service periodicly
calls an external tool that acts like a bulk copier (kinda like bcp) that
copies the data to the db and commits it in two phases;
Phase #1: Copying data to the db
Phase #2: Applying a sequence of DML on the copied data

If a machine shutdown or Service Stop is requested right after the service
invokes this external utility then the service cannot abort before the that
external tool returns (which could be the 6 mins that i was talking about).
This might cause data corruption if the process gets aborted in the middle.
So in most cases the service will return immediatly if its not waiting for
that utility to finish but in the situations where the shutdown/stop is
requested in the middle i dont really care if the machine waits 6 mins. I
care more about the data.
I hope this makes sense.
Thanks for the help.
-Ash

Avoid delays in service stop. Move the "external utility" to a server, and
wrap some sort of interface around it (web service would be easy). Provide
interface methods to submit, check status, etc. Your Windows service should
just submit a "save" request to the web service (including the data), then
can immediately stop. If necessary, it can track the submitted request on
stop, and later check status on start.

"Ash" <(E-Mail Removed)> wrote in message
news:61D3F982-73F0-4BA2-8FFD-(E-Mail Removed)...
> Nicholas,
> Thank you for the quick reply. Unfortunatly this is not an option because
> the process is not writing the data directly. Instead my service
> periodicly
> calls an external tool that acts like a bulk copier (kinda like bcp) that
> copies the data to the db and commits it in two phases;
> Phase #1: Copying data to the db
> Phase #2: Applying a sequence of DML on the copied data
>
> If a machine shutdown or Service Stop is requested right after the service
> invokes this external utility then the service cannot abort before the
> that
> external tool returns (which could be the 6 mins that i was talking
> about).
> This might cause data corruption if the process gets aborted in the
> middle.
> So in most cases the service will return immediatly if its not waiting for
> that utility to finish but in the situations where the shutdown/stop is
> requested in the middle i dont really care if the machine waits 6 mins. I
> care more about the data.
> I hope this makes sense.
> Thanks for the help.
> -Ash

Russell,
Thanks for the reply, but that could open an endless loop because the delay
will happen at some point or the other, what if that other server needs to be
rebooted (our servers are administered by a 3rd party that do not want to do
extra work when applying a patch or anything similar, they just want to hit
REBOOT and everything else should happen gracefully & automaticly).
Wouldn't that bring us to where we started ???
Thanks and I appreciate your thoughts...

On Tue, 18 Jul 2006 09:50:02 -0700, Ash wrote:

> Russell,
> Thanks for the reply, but that could open an endless loop because the delay
> will happen at some point or the other, what if that other server needs to be
> rebooted (our servers are administered by a 3rd party that do not want to do
> extra work when applying a patch or anything similar, they just want to hit
> REBOOT and everything else should happen gracefully & automaticly).
> Wouldn't that bring us to where we started ???
> Thanks and I appreciate your thoughts...

Production servers should only hav scheduled reboots - so don't initiate
your process before one of those times... If your 3rd party likes to reboot
your production servers on a whim, get another 3rd party!

Cheers

- Andrew

I would agree with you if we were living in a perfect world. But
unfortunately you have to design your application to be fail safe with all
these situations.
It would be bad if you corrupt your database because the SA rebooted the
machine a little early or late.
I'm sure you'd agree.

"Andrew" wrote:

> On Tue, 18 Jul 2006 09:50:02 -0700, Ash wrote:
>
> > Russell,
> > Thanks for the reply, but that could open an endless loop because the delay
> > will happen at some point or the other, what if that other server needs to be
> > rebooted (our servers are administered by a 3rd party that do not want to do
> > extra work when applying a patch or anything similar, they just want to hit
> > REBOOT and everything else should happen gracefully & automaticly).
> > Wouldn't that bring us to where we started ???
> > Thanks and I appreciate your thoughts...
>
> Production servers should only hav scheduled reboots - so don't initiate
> your process before one of those times... If your 3rd party likes to reboot
> your production servers on a whim, get another 3rd party!
>
> Cheers
>
> - Andrew
>