I have an MVC3 application that takes 30+ seconds for global.asax Application_Start() to execute. When a user hits the site for the first time after the App Pool was reset, the browser just sits there with a "waiting for website..." message.
Is there a way to show a "Loading data..." message/page to let the user know that everything is OK and to be patient?
No, there's no way to show any messages from Application_Start. IIS 7.5 has a cool AutoStart feature which allows you to preload your application in memory and thus avoid the long waiting. Another possibility is to have some external service that queries your site at regular intervals so that it doesn't get unloaded by IIS.
If you cannot use this feature, then you will have to reduce/optimize the amount of work you do in your Application_Start so that it doesn't take 30 seconds.
Not within the same .net application - you can't show anything from within Application_Start. You could create another small app as a landing page which polls for a response from your main app and then redirects once it gets one.
But a better solution would be to move some work out of Application_Start - can't you let the user arrive at your first page and then call an initialization method once they have landed?
You can't do that in that particularly way, as there is no response from the server, and for such, you can't do anything.
But how about to implement a heartbeat that will query any URL of your application avoiding it not to enter in stand mode?
an idea: Set an external service to query your application every 5 minutes:
RestSharp requests on momentapp's restful api
Related
I would like to fire a method 'ProcessBatch () ' to run every 'x' minutes when an ASP.Net app starts up.
I think I will have to add code for this to Application_Start event.
What is the best way of doing this, so that when the website has its app pool recycled then the scheduled task that is running is treated as a web request and allowed to complete?
You cannot create a scheduled task that runs "every x minutes" on a web server.
Some people write services that run on a client computer which pings the site every now and then. But for that you need that client to be up-and-running.
One workaround is, like you say, the Application_Start event, but your application may run longer than just a few minutes. We do not actually know when that is.
You could run your task someplace else, like the Session_Start event (whenever a new user opens one of your pages), or even the BeginRequest event if you write your own HttpModule.
In those events, you could remember the time the task was run for the last time (like a static, or in the ApplicationState maybe) to keep it from running hundreds of times per minute once your site has a huge load of users.
Hope this helps?
Also, depending on where your site is hosted, you may be able to use that provider's scheduled-task system. Azure has one, RackspaceCloud and DiscountASP.NET as well.
i run a background thread in Application_Start() in global.asax
to use it like windows service
but applicaton_end fire when all session is ended in my website
i have a sms Business that work with webservice and i want to have agent in my server that
check incoming message like windows service
i increase session timeout to 10 hours but when i close browser application end fired and
my thread stop working
i cant change server properties
can i disable application_end to thread keep working?
I apologize to you because of poor english writing
You should make a separate program that runs as a service or a batch program to do that. Although ASP.NET persists static variables and such between page loads, you shouldn't be using it to run things in the background. There is no guarantee that things will keep running.
If you need something to happen on the user's end when something happens on the server (like a message received (like on facebook), someone responds to a request, or some other event is raised) you need to implement a polling system in javascript on the webpage that the user sees which uses AJAX (look it up...its such an awesome concept) to periodically talk to the server to see if anything happened. That is how Facebook chat works along with most webmail systems to check for new messages. The server doesn't talk to the browser...the browser asks the server if anything happened.
Here is an example of a chat program that uses AJAX: http://www.dynamicajax.com/fr/JSON_AJAX_Web_Chat-.html
It isn't exactly what you are doing, but it demonstrates the concept of trying to check something after the page has been loaded and making the user's browser respond.
Nay be use a .NET version of quartz-scheduler library (http://quartz-scheduler.org/) for defining and triggering a job based on the configuration (cron expresion).
iis automatically close website application when no session is open in website
for disable this you can change idle time in iis or read website link in global.asax (application_end) function to start a new session
In sharepoint my web part is calling a web service. This web service does some heavey processing in the background. On large data sets the page asks for your username and password after a certin period of time before a response is returned. It seems to be timing out. What setting timing out and where do I change this limit?
http://support.microsoft.com/kb/912451 upping this value from 30 seconds has stop the autheication problem for me. Running into a new issue backend now for it timing out but the browser seems to be fine.
I am not able to make more than one request at a time in asp.net while the session is active. Why does this limitation exist? Is there a way to work around it?
This issue can be demonstrated with a WebForms app with just 3 simple aspx pages (although the limitation still applies in asp.net mvc).
Create an asp.net 3.5 web application.
There should be just three pages:
NoWait.aspx, Wait.aspx, and SessionStart.aspx
NoWait.aspx has this single nugget added between the default div tags: <%=DateTime.Now.Ticks %>. The code-behind for this page is the default (empty).
Wait.aspx looks just like NoWait.aspx, but it has one line added to Page_Load in the code-behind: Thread.Sleep(3000); //wait 3 seconds
SessionStart.aspx also looks just like NoWait.aspx, but it has this single line in its code-behind: Session["Whatever"] = "Anything";
Open a browser and go to NoWait.aspx. It properly shows a number in the response, such as: "633937963004391610". Keep refreshing and it keeps changing the number. Great so far! Create a new tab in the same browser and go to Wait.aspx. It sits for 3 seconds, then writes the number to the response. Great so far! No, try this: Go to Wait.aspx and while it's spinning, quickly tab over to NoWait.aspx and refresh. Even while Wait.aspx is sleeping, NoWait.aspx WILL provide a response. Great so far. You can continue to refresh NoWait.aspx while Wait.aspx is spinning, and the server happily sends a response each time. This is the behavior I expect.
Now is where it gets weird.
In a 3rd tab, in the same browser, visit SessionStart.aspx. Next, tab over to Wait.aspx and refresh. While it's spinning, tab over to NoWait.aspx and refresh. NoWait.aspx will NOT send a response until Wait.aspx is done running!
This proves that while a session is active, you can't make concurrent requests with the same user. Requests are all queued up and served synchronously. I do not expect or understand this behavior. I have tested this on Visual Studio 2008's built in web server, and also IIS 7 and IIS 7.5.
So I have a few questions:
1) Am I correct that there is indeed a limitation here, or is my test above invalid because I am doing something wrong?
2) Is there a way to work around this limitation? In my web app, certain things take a long time to execute, and I would like users to be able to do things in other tabs while they wait of a big request to complete. Can I somehow configure the session to allow "dirty reads"? This could prevent it from being locked during the request?
3) Why does this limitation exist? I would like to gain a good understanding of why this limitation is necessary. I think I'd be a better developer if I knew!
Here is a link talking about session state and locking. It does perform and exclusive lock.
The easiest way around this is to make the long running tasks asynchronous. You can make the long running tasks run on a separate thread, or use and asynchronous delegate and return a response to the browser immediately. The client side page can send requests to the server to check and see if it is done (through ajax most likely), and when the server tells the client it's finished, notify the user. That way although the server requests have to be handled one at a time by the server, it doesn't look like that to the user.
This does have it's own set of problems, and you'll have to make sure that account for the HTTP context closing as that will dispose certain functionality in the asp.net session. One example you'll probably have to account for is probably releasing a lock on the session, if that is actually occurring.
This isn't too surprising that this could be a limitation. Each browser would have it's own session, before the advent of ajax, post back requests were synchronous. Making the same session handle concurrent could get really ugly, and I can see how that wouldn't be a priority for the IIS and ASP.NET teams to add in.
For reasons Kevin described, users can't access two pages that might write to their session state at the same time - the framework itself can't exert fine-grained control over the locking of the session store, so it has to lock it for entire requests.
To work around this, pages that only read session data can declare that they do so. ASP.NET won't obtain a session state write lock for them:
// Or false if it doesn't need access to session state at all
EnableSessionState="ReadOnly"
I have an Ajax request to a web service that typically takes 30-60 seconds to complete. In some cases it could take as long as a few minutes. During this time the user can continue working on other tasks, which means they will probably be on a different page when the task finishes.
Is there a way to tell that the original request has been completed? The only thing that comes to mind is to:
wrap the web service with a web service of my own
use my web service to set a flag somewhere
check for that flag in subsequent page requests
Any better ways to do it? I am using jQuery and ASP.Net, if it matters.
You could add another method to your web service that allows you to check the status of a previous request. Then you can use ajax to poll the web service every 30 seconds or so. You can store the request id or whatever in Session so your ajax call knows what request ID to poll no matter what page you're on.
I would say you'd have to poll once in a while to see if request has ended and show some notifications, like this site does with badges for example.
At first make your request return immediately with something like "Started processing...". Then use a different request to poll for the result. It is not good neither for the server nor the client's browser to have long open HTTP sessions. Moreover the user should be informed and educated that he is starting a request that could take some time to complete.
To display the result you could have a"notification area" in all of your web pages. Alternatively you could have a dedicated page for this and instruct the user to navigate there. As others have suggested you could use polling to get the result.
You could use frames on your site, and perform all your long AJAX requests in an invisible frame. Frames add a certain level of pain to development, but might be the answer to your problems.
The only other way I could think of doing it is to actually load the other pages via an AJAX request, such that there are no real page reloads - this would mean that the AJAX requests aren't interrupted, but may cause issues with breaking browser functionality (back/forward, bookmarking, etc).
Since web development is stateless (you can't set a trigger/event on a server to update the client), the viable strategy is to setup up a status function that you can intermittently call using a javascript timer to check whether your code has finished executing. When it finishes, you can update your view.