I'm trying to make a simple scheduler service that will automatically send emails, etc.For now I have simple WCF service in which I create an instance of a timer, set a callback and do some work in the callback. Now this part works fine, with the callback being called and the work in it being done as expected.The issue is I need to make some change to the timer, say change the interval or maybe just stop it.But I can't seem to figure out a way to store/get the instance of that timer that I created. As each time I create a new proxy and access the service, I get a new instance of the service...I could use a static variable and store the reference to the timer in that but that would go against the 'stateless' nature of SaaSGrid's WCF services...So how can I get that instance of a timer/thread that I actually created in a previous call? Will I need to try to 'hang on' to a single global proxy?
Hi,
Given the fact that SaaSGrid's default behavior is to automatically reclaim idle WCF service instances (thus the best practice of remaining stateless), you have a couple of other options: the Interface layer or the DB layer.
1) The interface layer - a SaaSGrid-deployed ASP.NET front end runs in IIS just as all ASP.NET apps, so therefore you can establish a thread timer as part of that application (probably in the Application_Startup event handler in Global.asax, for instance). This timer should be a bit more consistent and reliable and you just want to have it fire the events by calling your WCF service.
2) The database layer - in this way, simply keep things how you have them - logic at the WCF service layer - but persist the parameters that define your timer so that when an instance of your WCF service starts up, it will grab that parameters for the timer from the application's persistence. This amounts to storing application settings.
You can also do a combination of these, or other tricks if you're feeling creative. One such approach is to keep the timer in the WCF service logic and have your ASP.NET application periodically call an empty Ping() method on your WCF service contract, doing this will prevent SaaSGrid's collection systems from automatically reclaiming the resources in use by your WCF service instance that contains the timer.
Let us know if you have any more questions.
"keep the timer in the WCF service logic and have your ASP.NET application periodically call an empty Ping() method on your WCF service contract, doing this will prevent SaaSGrid's collection systems from automatically reclaiming the resources in use by your WCF service instance that contains the timer."
I have tried this solution...there are a couple of problems I have with it...
1) IIS recycles application pools from time to time, due to heavy/light load etc, this results in the timer that was pinging our service to stop (eventually causing the service to stop as well)...the timer does not start again until someone visits a webpage on the website...
so far the only solution I have found to this is to have some external service (like mon.itor.us) to ping our website from time to time...
2) I've created a timer/thread in the service, but where do I store it's reference so that I can access it later to make changes to it?
Hi hsarwar,
Sorry we've been a bit delinquent in responding to this.
I will research your #1. In general IIS' app pools can be tuned for your specific usage, but I believe that yes, recycling is probably inevitable. (Does global app start fire on recycle?)
As far as #2, I believe if you implement a singleton around the timer, you ought to be able to access it without difficulty in all service contexts for the life of the app domain.
have you solved this? I implemented a scheduler in our application, it has some small issues, but its working fine most of the time, if you want I can provide you with more detail.
Pedro Ramírez Developer at Scio Consulting
Hi
Yes I did manage to solve this. Instead of pinging the service from the website to keep it alive, I hit the website from the service. The page I hit in turn calls a dummy function in the service. So the website and service kind of keep each other alive perpetually.
It worked perfectly for around the 4 odd weeks that I had it running.
But I did have to use static variables to hold instances to the timer that I was using, so the service is not scalable, but I think a singleton service is good enough for a simple scheduler.