-1

i am working on global.asax in mvc, what issues i'm facing is,i have set a scheduler to start global and its working well but after starting the global i got data, but suppose data is not available upto next 20 min global process has stopped. now after 20 mins data is came from server but the global is stop so i cant get the data from global. now the question is, how can i increase time of global process to 60 min or something..or how can global starts whenever data came.

here is my code

  protected void Application_Start()
    {
        AreaRegistration.RegisterAllAreas();
        FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters);
        RouteConfig.RegisterRoutes(RouteTable.Routes);
        BundleConfig.RegisterBundles(BundleTable.Bundles);


        System.Timers.Timer timer = new System.Timers.Timer();
        timer.Interval = 300 * 1000;                 //60*1000 means 1 min 
        //timer.Enabled = true;
        timer.Elapsed +=new System.Timers.ElapsedEventHandler(Daily_Attendance_RFID);
        timer.Start();
        Application.Add("timer", timer);

    }

    static void Daily_Attendance_RFID(object sender, System.Timers.ElapsedEventArgs e)
    {
        //***   For RFID Attendance Function   ***//
        Daily_Attendance.Daily_Attendance_RFID();
    }

1 Answers1

6

Short version:

You should not have a Timer under a hosted environment. That is a bad practice, period.

Long version:

The reason for this goes pretty deep in how ASP.NET started, and "why" things are where they are today.. but I will try my best to explain using the little knowledge I've got.. two general points to consider:

  1. Your app (at least eventually...) runs under IIS process, which is a Windows service (World Wide Publishing Service - W3SVC). IIS (..or better say: W3SVC.exe process..) is your hosting environment, and it runs every app/website using an Application Pool. Each app pool gets to run 1 (or more) w3wp.exe processes (little nice to know: if there are more than one w3wp handling that app pool - they call that pool a Web Garden..)

  2. Generally, any process running under Windows gets to have 1 (or more..) AppDomain. Each AppDomain gets to have a scoped session that holds all static variables or threads, or thread related resources.

In your case - Timer uses threads/locks to elapse the callback delegate when the time arrives.. so the environment in which you are initializing a Timer matters. If this was a STA/MTA environment (Windows/GUI app or services) - by all means - you could have a Timer, because your app would (usually..) be running under 1 process - and that one process (usually...) gets to have one single AppDomain.

The other downside to initializing a long-running background process (like a thread that waits to elapse a callback - or Timer..) under a hosted environment is that - the external environment has the control over your application life cycle. It might shut it down, or put it into Idle (How to configure Idle settings in IIS) because of various reasons which might differ from machine to machine.. Take this for instance: Someone might simply just recycle the Application Pool running your app, and your Timer would go away, and get initialized all over again..

Suggestion:

If you can - separate the Timer logic into a Windows service. If not - try to use a Task scheduler instead, like FluentScheduler, Quartz and a lot more out there.

Rikki
  • 3,338
  • 1
  • 22
  • 34
  • Hey, thanks for the answer. I realized that though I know it's a bad practice, I don't know why. Could you elaborate on what exactly could go wrong because of the timer grabbing the locks and starting threads in our w3wp process? I mean, there could be a ton of other guys doing the same in our ASP.NET app, why it's only the timer who's bad? – vorou Aug 10 '17 at 07:22
  • No problem. Answer me this: What happens if IIS decides to initialize more than one AppDomain? Does that mean you will have two Timer's running at the same time? What if there are more than 1 w3wp processes running? In all these questions, the answer is unclear from your app's perspective. The same thing goes with task schedulers, but still they do have some mechanisms to prevent certain situations from happening. – Rikki Aug 10 '17 at 12:43
  • 1
    Thanks, I got this: it's hard to control the lifecycle of the timer because it would be tied to your web app lifecycle which is controlled by IIS in an unpredictable way. – vorou Aug 11 '17 at 08:18