I'm using a simple windows service app. Some of the code takes around a minute to finish executing. If I want to rollout news changes to production, how do I ensure that even after I stopped the service, the service finished what ever it's executing?
Your new service would need to check to make sure the old process isn't running.
How can I verify if a Windows Service is running
A better way would be to fix your service so it can be shutdown in a reasonable length of time. A minute is much too long to stop a service.
Whatever it's doing needs to be able to cleanly stop or roll back on request.
Related
A test WCF webservice that I have hosted using IIS 7.5 is consistently slow to respond to calls made after a period of inactivity (i.e. the first call of each day).
From researching this topic I gather that the problem of "application warmup" is commonly encountered when using IIS (e.g. see here).
I have taken the usual steps that are recommended to try and mitigate this problem:
Installed the Application Initialization Module.
Disabled the application pool Idle Time-out, and the Regular Recycling Time Interval (i.e. set them to '0').
Edited the applicationhost.config file so that autoStart=True and startMode="alwaysRunning" for the necessary app pool, and preloadEnabled="true" for my application.
With these settings, I expect the application pool to immediately spin up a worker process when IIS is started, and spin up a new worker process when the existing one exits. Also, I expect the application to be loaded within the worker process.
However, for the first call of each day, the logs show the difference in time between the client making a call, and the webservice receiving the call, can be as much as 10 seconds. Subsequent calls are typically handled in well under 2 seconds.
Curiously, the long response time is not reproduced by making a call following an iisreset command. I would expect that such a heavy-handed operation would put the webservice in a similarly "cold" situation, however this does not seem to be the case.
I would like to know:
What could still be causing the delay in the application "warming up"?
What is the difference in the state of the webservice following iisreset and a long period of inactivity?
Should I resort to a "heart beat" solution to regularly ping the service to keep it alive?
Thanks in advance for any tips or insight.
I'll try to help with you questions:
What could still be causing the delay in the application "warming up"?
Warm up an application does not mean warm up its resources. For instance, if you configure Auto-start with Application Fabric in your WCF application (https://msdn.microsoft.com/en-us/library/ee677260(v=azure.10).aspx), and this application access database using EF, it will not initiate your DBContext.
If you want these resources initialized after your application warmed up, you need to implement a method to initialize your resources, like cache, DBContext, etc.
What is the difference in the state of the webservice following iisreset and a long period of inactivity?
When the application spend long time of inactivity, probably the application pool goes down and it is restarted when it receives any request, like a recycle does.
This link has interest information about the difference between iisreset and application pool recycle, and it can help to answer your question: https://fullsocrates.wordpress.com/2012/07/25/iisreset-vs-recycling-application-pools/
Should I resort to a "heart beat" solution to regularly ping the service to keep it alive?
If you keep on accessing your service, it will probably keep its resources initialized in memory, so can be a good approach.
Anyway, if your Application Pool is configured to recycle in some interval time, it will be recycled and your resources in memory lost.
If it looks problem to you, just turn off this feature going to IIS -> Application Pool -> Advanced settings and set Regular Time Interval=0
For this issue, it's just some suggestions, you need to make some tests and find out the better solution.
How to host a Windows Service in IIS and keep that service runing like it is running on Windows?
Could I use some feature from WCF service?
I've not access to the Windows itself, only to IIS. Inside that service I'll create a thread which at scheduled time will process some data.
In short, you can't.
A more detailed answer is that there are 2 problems:
IIS worker processes are launched only when a HTTP request comes in. This means you can't start your service with the system.
IIS worker processes are recycled (i.e. restarted) on several conditions. For example, a worker process is restarted if no HTTP request comes in for a long time. This means you can't control when your service is shut down, unless you have access to application pool recycling configuration. Keep in mind that the recycling logic only ensures that all pending HTTP requests are complete, but does not await all background threads to complete.
You can come with a partial solution this way:
Create a WCF service method that checks if your long-running thread is alive and if not, starts it.
Create a very simple windows service that periodically (once in 5 seconds) calls that method. Deploy the service somewhere, e.g. on your own machine.
The only question that remains is: do you really need to avoid windows services? Could you find a place to host the service? There are some use cases when a windows service is the best or even the only way.
You cant, in a nut shell.
However you can make use of the health monitoring API specifically the heartbeat functionality. see:
http://msdn.microsoft.com/en-us/library/system.web.management.webheartbeatevent.aspx
for details on the class you will need to implement to be called when there is work to do
also this answer on SO might help
Understanding heartbeat in ASP.NET health monitoring
Once you have implemented a webheartbeatevent derived class you can check your db or what ever you want to check if there is work to do.
A better solution IMHO is to scrap the service entirely and redesign the system to be 100% web based, as services become a deployment and maintenance nightmare. as i assume you are now finding out...
Currently I am using Windows Service to keep on running some jobs in the background. These jobs are scheduled via Quartz.Net. Generally these are long running jobs, spans from 5 min to 15 min. If a job is currently running and if User will try to Shutdown the Windows Service then it throws Exception: Windows service did not respond in a timely fashion.
Actually OnShutdown() method of WindowsService, I am trying to Shutdown the Quartz.Net also.
I am calling scheduler.Shutdown(true) to stop the scheduler & wait for running jobs. If I will make this False then Windows Service Stops normally but it will put the running Job in Unstable state. Please help me on this.
You get this error because your service did not complete the Stop in the agreed-upon time. So, the SCM assumes it's hung in some way and aborts it.
To tell the SCM you need more time to complete the operation, call ServiceBase.RequestAdditionalTime() in your OnStop handler. For more information see http://msdn.microsoft.com/en-us/library/system.serviceprocess.servicebase.requestadditionaltime.aspx
I am using C# to write a program that uses a web service from http://msrmaps.com, the problem is sometimes (seemingly at random) the site won't work properly and will return a few different exceptions. Then on subsequent attempts to use the service I get the error over and over, then after a while (sometimes 30 minutes) the service starts working properly again. In order to avoid waiting for the service to work properly again, I usually just close my program and start it back up again. Usually that fixes the problem and I can continue to use the web service.
My question: Is it possible to restart my program within the program or better yet is there a way to somehow re-connect to the web service like the program does when I first run it?
What is the program actually doing that depends on the web service? Does it really need to be re-started? It sounds like you should be able to just have some UI element in the application that attempts to connect to the service. Wrap that connection in some exception handling and somewhere in the application's UI display that the service connection is currently unavailable.
Or am I way off here?
Warning: This is a bit of a hack, but it works.
I'm assuming your application is unattended, so a UI change alerting the user to the need to shut down and restart is not an option.
We had a similar situation where the simplest resolution to a problem was to shut down and restart my app. (We'll call this "App A").
What I wound up doing was writing a second executable (We'll call it "App B") as a console app that did two things.
It used the System.Diagnostics.Process to kill any instance App A.
Use System.Diagnostics.Process to re-launch App A after all instances were killed.
Then in App A, I had a try/catch around the offending code, and when the error I was looking for came up, it would call App B.
This was the only way I could find of killing a program and relaunching it. If anyone has a better solution, PLEASE post it and I'll change my hack to use a better solution.
I would check that you don't have too many simultaneous requests happening at the same time due to each waiting for a long time before returning (and relatedly, that the total allowed connections as per machine.config is high enough). Throttling code can be very useful with unattended use of web-services (or any other remote service), if you've had a few failures in a row then wait a while before allowing another request to be made (I like to roll forward the wait period each time, starting a around a minute, maxing the wait at around 10minutes).
Then while you can't guarantee the other service won't go down, you can help prevent it causing a permanent problem, or reducing the performance of other processes.
I'm having an issue that I can't figure out regarding a Windows Service I have written in C#. What I am trying to do is wait for a specified period for a child process to terminate before I am forced to kill it and stop the service. I have set my timeout for anywhere from 5 to 15 seconds and my service waits the appropriate amount of time and then kills the child and stops when I stop it via the mmc service window. However if I shutdown the computer my service gets blown away before it is able to wait and stop properly. I have read that Windows allows for a timeout of 30 seconds for a service to shutdown before it blows it away. My code is executing in much less time than 30 seconds, max is around 20 seconds or so, depending on what I set the timeout at.
I have tried using the SetServiceStatus() function in the win32 Api but it has not changed the function of the code. I have verified that the function call is succeeding. Is there any other way to force Windows to wait for my service to shutdown properly? I am testing it in Windows 7 x86, and Windows Vista Sp1 x86.
Windows will not let any service prevent shutdown, this is by-design. as Gyuri says, you have to consider a different design for your app.
This is a global Windows setting, apparently: http://support.microsoft.com/kb/305788. I would be worried if I had to rely on the users to let my service shut down. I would save my data periodically instead.
OnSTart and OnSTop are inherited from a base class which does quite a bit for you. All your implementations of these methods should do is start or stop your client code, windows will do the rest.
I'll caveat this with the fact that I use C# and .Net's implementation of ServiceBase does this, I cannot talk authoritatively about C/C++ code or APIs.