I have a windows service that will be started(remotly) when it is called. I dont want to keep service running so I want the service be self-stopped when enter in idle time, means few minutes after the last call.
I dont want to stop the service from my remote client because I dont know if I finish to work with, that's why I want to use some Idle event in service side.
There is some way ?
thanks,
Add a timer in the Windows Service which is reset on each call. When the timer elapses (some number of minutes later) have it call the service's Stop method, effectively stopping the server once it becomes idle.
Additional Info
In order to reduce your coding overhead you're looking for an intercept point to handle this timer. If you're using WCF for your service calls the simplest way to do that is with a custom IParameterInspector added as a service extension. You can add the timer logic into the AfterCall() method so that every service call runs through this same block of code & resets the timer. See this MSDN article for details on implemnting custom behaviors.
If you aren't using WCF it's a little trickier. You could use an AOP framework like Castle Windsor or PostSharp, or design your service in a message passing style. AOP allows you to decorate your methods with a property that will call your reset code. Message passing involves desigining your service's contract such that there is a single generic entry point into the service which inspects the incomping message & routes it to the correct method based on it's contents. As you can imagine, one entry point = one place to add the timer reset code. But neither of these are as clean or easy to implement as the WCF-based solution IMO.
Related
I have a console service I'm currently testing. I was planning on using a timer for it to last all day, with an interval check every 30 seconds, however, it looks like alot of people don't like using timer's with a service in that fashion. Is It wise to use a timer? or is their a better method to approach it?
It's fine to have timers inside a service.
The question you should be asking yourself is whether you need your own service, or can just leverage a service that's already running timers (Task Scheduler). Or perhaps you should instead be responding to a user action.
I suspect they are trying to get you to do it using a thread based method this way, which is arguably superior as the wait method is designed to awake correctly in response the the service interface.
If you need to launch very frequently the service approach is better than a scheduled task.
I've got a windows service with only two methods - one private method DoWork(), and an exposed method which calls DoWork method. I want to achieve the following:
Windows service runs DoWork() method every 6 hours
An external program can also invoke the exposed method which calls DoWork() method. If the service is already running that method called from the service, DoWork() will again be invoked after the current method ends.
What's the best approach to this problem? Thanks!
An alternative approach would be to make use of a console application which can be scheduled by Windows task scheduler to run every 6 hours. In that case you don't waste resources to keep the Windows service running the entire time but only consume resources when needed.
For your second question: when you take the console app approach you can have it called by making use of Process.Start for example.
If the purpose of your application is only to run a specific task every six hours, you might be better off creating a command line application and creating a scheduled task that Windows runs automatically. Obviously, you could then manually start this application.
If you're still convinced you need a service (and honestly, from what I've seen so far, it sounds like you don't), you should look into using a Timer, but choose your timer carefully and read this article to get a better understanding of the timers built into .NET (Hint: Pay close attention to System.Timers.Timer).
To prevent reentry if another method tries to call DoWork() while the process is in the middle of performing its operation, look into using either a Mutex or a Semaphore.
there are benefits and drawbacks either way. my inclination with those options is to choose the windows service because it makes your deployment easier. scheduling things with the windows task scheduler is scriptable and can be automated for deployment to a new machine/environment, but it's still a little more nonstandard than just deploying and installing a windows service. you also need to make sure with task scheduler it is running under an account that can make the webservice call and that you aren't going to have problems with passwords expiring and your scheduled tasks suddenly not running. with a windows service, though, you need to have some sort of checking in place to make sure it is always running and that if it restarts that you don't lose hte state that lets it know when it should run next.
another option you could consider is using nservicebus sagas. sagas are really intended for more than just scheduling tasks (they persist state for workflow type processes that last for more than the duration of a single request/message), but they have a nice way of handling periodic or time-based processes (which is a big part of long running workflows). in that a saga can request that it get back a message from a timeout manager at a time it requests. using nservicebus is a bigger architectural question and probably well beyond the scope of what you are asking here, but sagas have become how i think about periodic processes and it comes with the added benefit of being able to manage some persistent state for your process (which may or may not be a concern) and gives you a reason to think about some architectural questions that perhaps you haven't considered before.
you can create a console application for your purpose. You can schedule the application to run every 6 hours. The console will have a default method called on application start. you can call your routine from this method. Hope this helps!!
I have several WCF services and I want to execute methods in them at specific intervals.
For example, call Service1.DoSomeWork every 5 minutes and Service2.DoSomeWork every 10 minutes. I also want Windows client applications to be able to call the DoSomeWork methods at any time.
What is the best way to implement this?
I have complete control over the server so using Scheduled Tasks is possible but I wonder if using a Workflow in AppFabric is better or using a timer in the service itself?
Check out this post. I answered a question a while ago where the developer want to "Do something" at an interval in a windows service. I gave a pretty detailed code sample for scheduling activity within a Windows Service as recommended by other posted earlier in this thread.
how to make service act dynamically based on service running condition
I'm not familiar with AppFabric but if I were you, I will use the timer since your requirement sounds simple.
If I were your ,
I create a windows service in the server .
So that I can do anything at specific intervals....
I'm a total noob at workflow!
I want to host several workflows (not as a service, bog standard workflows); however i also want them to share a common activity (ActivityX). Now ActivityX should block / idle the current workflow, until it gets a receive call.
Can I re-use this activity? I'm guessing I need to make it a service, asmx? But then how to make it block the workflows that it's used in - if I drag it on to those workflows that tries to invoke the service, rather than just wait until that call happens.
Can anybody make some suggestions? It doesn't necessarily have to be a receive activity, but I need a convenient way of idling the workflow until a particular object (or if needs be, a set of parameters) arrives.
I'm quite stuck and clearly missing something in my very poor understanding of WF 4.0.
Thanks,
Pete.
If you use a Receive activity you have to use a WorkflowServicehost as the host and can't use a WorkflowApplication or WorkflowInvoker as it depends on the WCF infrastructure from the BaseServiceHost.
Creating blocking activities is done using a bookmark. You create a bookmark and the workflow stops until you resume that bookmark, at least with the default options. In fact the receive activity does exactly this as part of making the workflow wait for the WCF message.
In C#, what is the best way to create a polling mechanism? So I have some code which can periodically do some action.
This is for web services so any UI-related solutions won't apply.
Thanks
If you are saying that you have a web service which is supposed to periodically take some action on it's own, then I think you haven't quite got the web services model. Web services are supposed to sit there (just like a web page) until something kicks it off.
Otherwise you are dealing with a very brittle situation where anything could cause it to just stop.
If you have a bit of code that needs to run on a timer, then you should investigate placing that code in a windows service (not to be confused with Web Service). That's what they are for.
"code which can periodically do some action" is called a "Timer". Search MSDN, you'll find three or four classes for the purpose, several of which are non-gui (System.Threading.Timer comes to mind).
EDIT: To whom do the changes need to be visible? If they are only visible to other consumers of the web service, then one approach is for each incoming request can check whether a periodic action is overdue and perform it. However, you shouldn't do things this way if (1) the changes need to be visible to e.g. other clients of the same database, or (2) the periodic changes need greater permissions than arbitrary incoming requests. Also, the periodic actions might be interrupted if the client cancels their request, and doing the actions might significantly delay the response to the client. For these reasons I don't recommend adding periodic processing to normal request/response processing.
Take a look at the System.Threading.Timer class. This makes periodic calls to a method you supply. These calls are made on a separate thread (a thread in the thread pool).
You'll want to use a timer.
There are a few timers in the .NET framework, including:
System.Timers.Timer
System.Threading.Timer
System.Windows.Forms.Timer
See this article for help choosing the right one: Comparing the Timer Classes in the .NET Framework Class Library
It sounds like you want a Timer, but that does not make sense to use in a Web service. It would make more sense if the timer was in a client. What clients use your web service?