I have a task that I want to be run 8am daily and am considering this solution: https://blog.stackoverflow.com/2008/07/easy-background-tasks-in-aspnet/
But I'm not understanding the mechanics of how it works.
Say user X visits the site on Friday at 4pm and then closes his browser and turns his computer off. Will the cache expiration still fire on Saturday at 8am? If no users visit the site, will my process still fire every day?
Basically, my question boils down to, is this method reliable? Or is it dependent on users visiting the site?
ASP.NET Application When hosted (started) on IIS fires few Events, of Which Application_Start is one of the foremost. Setting a Background task then keeps running untill the Application is stopped/unloaded from IIS, or IIS service itself is stopped. IIS is a host process for all ASP.NET Websites.
Since the Cache is maintained on the Web Server, it has nothing to do with the active user(s).
This is analogous to a console aplpication, where the first line of code is adding something to a cache with a timer. runs as long as your console application is up and running.
Hope this helps you!
The server side cache is different to the browser cache. Users closing their browsers won't effect Jeff's code at all. However, if your application pool shuts down (and it may if there aren't any users hitting the site) then your code won't run at all until someone browses to the site, the app pool spins up again, and then it's 8am the next day (assuming the app pool is still up).
Related
I have a ASP.Net MVC Website Hosted on IIS on couple of servers with load balancers, it a very simple page when it opens it logs user details in DB and show the view.
Issue is: It becomes unreachable sometime and pages are never opened. I have to restart APP Pool to get back on track and then it happens again.
What I have tried:
Made sure all DB connection are properly handled, any connection that gets opened are surely closed
Have put Recycle of APP Pool based on volume of RAM
Went through IIS logs and checked that request have reached there or not
There are other application also running on Server but the problem is isolated to this website
There are global users, issue persist of different global area
What I think it can be:
Might be possible that Load Balancer is never diverting my request
My request getting lost in between networks and layer
This is Production environment and we are not facing this issue in ACC or Dev.
What else I can go ahead and check?
In my ASP.NET project, I am using Forms authentication. My main.master using LoginStatus control and web.config is set up for "Forms" authentication mode.
Before I log in, the control shows the text as "Login." After I log in, the control shows the text as "Logout." This is expected. However, after clicking around on a few links within the site, the control suddenly starts showing "Login" although I am still logged in. The session is still alive as some of the pages I visit dumps some session information.
Would appreciate if something can point me in the right direction. Regards.
If you are trying to redirect after setting a Session variable using
Response.Redirect("YourPage.aspx");
this may be causing the session token to gets lost, try using the overloaded version of Redirect:Response.Redirect("~/YourPage.aspx", false);
Another problem also may be miss configuration of application pool. If the application pool is configured as a web farm or a web garden (by setting the
maximum number of worker processes to more than one) and if you're
not using the session service or SQL sessions, incoming requests will
unpredictably go to one of the worker processes, and if it's not the
one the session was created on, it will get lost.
The solutions to this is either not to use a web garden if you don't need the
performance boost, or use one of the out of process session
providers.
For more information you can check the link of the original article below: http://weblogs.asp.net/bleroy/Don_2700_t-redirect-after-setting-a-Session-variable-_2800_or-do-it-right_2900_
Let's suppose I have an ASP.Net web application hosted by IIS. In addition to the functionality serving requests I added an action executed periodically on specified interval, e.g. every 30 minutes. This action is not related to external web requests, for example, its purpose is deleting useless log files.
The question is: if nobody comes to my web site for long period of time (day, week) will IIS still keep my application alive and the above action will be executed every 30 min. Or IIS will shut down/suspend activity of the application if there are no requests for long time?
Perhaps it is a lame question but I failed to find the definite answer.
IIS doesn't shut down, but IIS will recycle your app after a certain period of time of unuse.
So if your app is responsible for firing off the event, then no it won't run if your app is not running (recycled).
Either have a service hit your website once in awhile or setup a scheduled task on the server if you have access to the machine.
If you're on shared hosting you'll have to check their features to see if they have something like that.
Also, if you're just trying to delete log files or something trivial and not time sensitive (since you won't have logs unless someone is hitting your site), you could just perform your action in Application_Start. This even will fire whenever IIS restarts your application.
I have an application in classic asp running on IIS 7. The website uses global ASA (Application_OnStart and Session_OnEnd, the others are not being used)
The problem is this. When one user logs in/out, sometimes the entire site does some sort of IIS reset and all the visitors of that site will have their sessions all reset. If any visitor was logged, it kicks them out and they have to login again.
There is some sort of activity triggering this mass session reset, or better yet, IIS reset, because it only happens sometimes. I am not sure what could be causing it.. Any suggestions?
Use the "Recycling..." action on the relevant Application pool in IIS Manager to check the Recycling conditions.
Anything that causes recycling of the application pool will result in the loss of all current sessions. Use the same dialog to turn on logging of recycles (if not already on).
Use event log to track any recycles and their cause.
Internet Information Services (IIS) application pools can be periodically recycled to avoid unstable states that can lead to application crashes, hangs, or memory leaks. Please check this event id on technet. It explains a bit more.
If you disable recycle settings and your application is buggy then there is lots of chances of your website getting down. Recently I also increased the session timeout of my website but it was timing out 12:45 irrespective of ilde time out. Hence I shifted the recycle settings to 20:00 during non buiness hours. So that it can clear all the unwanted app pools.
Can I objectively determine if my production ASP.NET web application is resetting its application pool? It could be for whatever reason (for example, an error occurred or memory topped off). I don't have direct access to my production servers, so when I want something on the server, I have ask specifically for it like PerfMon counters to run. It is a running IIS 6.0.
I understand that I could use PerfMon to catch ASP.NET Application Restarts. If I was not monitoring that PerfMon, is there anything that can tell me the application restarted sometime in the past?
You'll need access to the Event Logs.
Depending on your IIS version you might have to enable the worker processing recycling events.
For IIS 6: http://technet.microsoft.com/en-us/library/cc756146(WS.10).aspx
For IIS 7: http://www.iis.net/ConfigReference/system.applicationHost/applicationPools/add/recycling
For more info, ask again on serverfault.com
If all you really care about is if the application resets, you can just add some sort of Email alert, or logging, in the Application_Start of your global.asax.
This would tell you when, and how often, the application starts up, but wouldn't give you any details as to why it happened.
This would at least give you the information you needed to look at specific times for when your application is resetting.