I saw an example of forever iframe implementation ( comet simulation ) , so I decided to test it but with the addition of asynchronous approach , so that there will be no blocking.
Pretty simple :
I have a page (index.html) with hidden iframe which has SRC of AdminPush.aspx:
/*1*/ protected void Page_Load(object sender, EventArgs e)
/*2*/ {
/*3*/ UpdateMessage();
/*4*/ }
/*5*/
/*6*/
/*7*/ protected void UpdateMessage()
/*8*/ {
/*9*/ HttpContext.Current.Response.ContentType = "text/html";
/*10*/ Response.Write("<script >parent.UpdateMessage(DateTime.Now.Second)</script>");
/*11*/ Response.Flush();
/*12*/
/*13*/ //async part goes here !!
/*14*/ this.RegisterAsyncTask(new PageAsyncTask(async cancellationToken =>
/*15*/ {
/*16*/ await Task.Delay(2000, cancellationToken);
/*17*/ UpdateMessage();
/*18*/ }));
/*19*/ }
On the AdminPush.aspx Page I added :
Async="true"
On the html page (index.html) I added :
function UpdateMessage(Message)
{
console.log(Message);
}
function setupAjax() //body Onload - calls it.
{
var iframe = document.createElement("iframe");
iframe.src = "adminpush.aspx";
iframe.style.display = "none";
document.body.appendChild(iframe);
}
So basically the iframe is being injected with script comands , which updates the parent of the iframe which is index.html.
It is working.
But when I tested it - it stopped updating after 45 seconds.
I thought it had to do with requestTimeout prop in web.config - but it wasnt.
It was related to the missing AsyncTimeOut prop in the AdminPush.aspx page.
Question #1:
According to msdn AsyncTimeout :
Gets or sets a value indicating the time-out interval used when
processing asynchronous tasks.
But it also says :
A TimeSpan that contains the allowed time interval for completion of
the asynchronous task. The default time interval is 45 seconds.
please notice that I "delay" 2 sec every time
at first I set the timeout to 1 minute , but then it failed also. I thought that the timeout should be regarding each operation , and not to sum(all async operations)
Why is it like that ? it suppose to be timeout for async task ! (single) but it behaves as sum(tasks)
The wording here are misleading. any clarification ?
Question #2:
I need to set it to max value. what is that value ? but still , I need it so support a browser for a very long time. so I'm afraid that this value won't help either.
Is there any way I can RESET this value (after n cycles) ?
I know that there are other solutions/libraries like signalR which are doing the job, still, it does not prevent learning how other stuff are done.
The idea of Asynchronous Pages is to free IIS so more users can be served, if you create a page that "never" finishes, you will eat up all your resources.
That been said... if you still want to do it...
We "know" (documentation), Asynchronous Pages work by splitting the execution of the page in 2... everything BEFORE the Background Tasks and everything AFTER the tasks, in that way IIS can process more requests while the background tasks finish their work. (there is more to it, but that is enough for now)
So... they "must" be creating some kind of Task Manager (like a root/main task) that executes all the registered tasks in sequence, in that way IIS starts processing the page, fires up the task manager, frees IIS, the task manager keeps processing the tasks and when it finishes, it returns control to IIS.
That would explain why the AsyncTimeout controls all the registered tasks instead of one-by-one (The timeout is actually applied to the Task Manager).
I tested a variation of your code with a timeout of 6000 seconds and it works:
C#:
protected void Page_Load(object sender, EventArgs e)
{
Page.RegisterAsyncTask(new PageAsyncTask(ProcessTask));
}
protected async Task ProcessTask()
{
await Task.Delay(1000);
Response.Write(DateTime.Now.ToLongTimeString() + "<br/>");
Response.Flush();
Page.RegisterAsyncTask(new PageAsyncTask(ProcessTask));
}
aspx:
<%# Page Language="C#" AutoEventWireup="true" CodeBehind="Default.aspx.cs" Inherits="Sample03.Default" Async="true" AsyncTimeout="6000" %>
Hope it helps.
Related
I have a UserControl(uc) in my master page, and a method(MyMethod) inside uc that make some calculations.
protected void Page_Load()
{
If(!IsPostBack)
MyMethod();
}
private void MyMethod()
{
SomeCalculations..
}
Because my uc is in master page, i can see the uc in all my aspx pages. My aim is that as soon as a user login the application, run MyMethod() just once (in a thread) and do calculations in an infinite loop until the user logout or application (or browser) closed. Although the calculations are outside of the PostBack, MyMethod will be called more than one time.
Assume that I m in Page-1 and it s loaded first time, MyMethod() will bi called. After another page (Page-2) is loaded, MyMethod will be called again and I want to prevent it. Is there a way to do something like this:
if(LifeCycle of application resumes)
{
MyMethod()
}
You can store a flag in application state and use it in a condition. Something like this, perhaps:
// in Application_Start in Global.asax
Application["IsRunning"] = false;
then:
private void MyMethod()
{
if (!((bool)Application["IsRunning"]))
{
Application["IsRunning"] = true;
// your code
}
}
Note that the state of a web application isn't always stable or intuitive. It's really meant to be a request/response system and is at the mercy of the web server for managing resources. This may not be as reliable as you expect.
You might want to consider having a separate application, such as a Windows Service, for performing ongoing background tasks.
I have a process that takes a long time to finish executing, the user should be able to see a simple feedback when the process starts and finishes
something like this:
protected async void Button1_Click(object sender, EventArgs e)
{
TextBox1.Text = "Process started..\n";
System.Diagnostics.Stopwatch sw = new System.Diagnostics.Stopwatch();
sw.Start();
await ProcessDelay();
sw.Stop();
TextBox1.Text += "Process finished.\n";
TextBox1.Text += "Elapsed Time (ms): " + sw.ElapsedMilliseconds.ToString() + "\n";
}
private async Task ProcessDelay()
{
await Task.Delay(5000);
}
Text value in TextBox is not updated until the execution of ProcessDelay() is done. What am I missing here?
Remember that when you're working with ASP.NET, you are working within a strict request+response paradigm. WebForms tries to hide this from you, but it's still one-response-per-request underneath. So, when you click a button in your browser, it sends a request to the web server, which executes the click code, returning a result. It can only return one result. So there's no way it can, say, make a change to part of the page and then later make another change.
To put it another way, async on ASP.NET yields to the ASP.NET runtime (that is, it returns the request thread to the thread pool). It does not yield to the browser (that is, it does not return a response).
To do what you want, you'll need an alternative technology. If the background work doesn't take too long, you could consider SignalR. Otherwise, you'll probably need a proper distributed architecture: a reliable queue connected to an independent background process. I describe a few approaches on my blog.
I understand (now) that Response.Redirect() and Response.End() throw a ThreadAbortException as an expensive way of killing the current processing thread to emulate the behaviour of ASP Classic's Response.End() and Response.Redirect methods.
However.
It seems intermittently in our application that the exception bubbles too high. For example, we have a page that is called from client side javascript to return a small string to display in a page.
protected void Page_Load(object sender, EventArgs e)
{
// Work out some stuff.
Response.Write(stuff);
Response.End();
}
This generally works, but sometimes, we get the exception bubbling up to the UI layer and get part of the exception text displayed in the page.
Similarly, else where we have:
// check the login is still valid:
if(!loggedin) {
Response.Redirect("login.aspx");
}
In some cases, the user is redirected to login.aspx, in others, the user gets an ASP.NET error page and stack dump (because of how our dev servers are configured).
i.e. in some cases, response.redirect throws an exception all the way up INSTEAD of doing a redirect. Why? How do we stop this?
Have you tried overloading the default Redirect method and not ending the response?
if(!loggedin) {
Response.Redirect("login.aspx", false);
}
You can use the following best-practice code instead, as explained by this answer to prevent the exception from happening in the first place:
Response.Redirect(url, false);
Context.ApplicationInstance.CompleteRequest();
Since I was looking for an answer to this question too, I am posting what seams to me a complete solution, rounding up the two above answers:
public static void Redirect(this TemplateControl control, bool ignoreIfInvisible = true)
{
Page page = control.Page;
if (!ignoreIfInvisible || page.Visible)
{
// Sets the page for redirect, but does not abort.
page.Response.Redirect(url, false);
// Causes ASP.NET to bypass all events and filtering in the HTTP pipeline
// chain of execution and directly execute the EndRequest event.
HttpContext.Current.ApplicationInstance.CompleteRequest();
// By setting this to false, we flag that a redirect is set,
// and to not render the page contents.
page.Visible = false;
}
}
Source:
http://www.codeproject.com/Tips/561490/ASP-NET-Response-Redirect-without-ThreadAbortExcep
Our ASP.NET 2 web application handles exceptions very elegantly. We catch exceptions in Global ASAX in Application_Error. From there we log the exception and we show a friendly message to the user.
However, this morning we deployed the latest version of our site. It ran ok for half an hour, but then the App Pool crashed. The site did not come back up until we restored the previous release.
How can I make the app pool crash and skip the normal exception handler? I'm trying to replicate this problem, but with no luck so far.
Update: we found the solution. One of our pages was screenscraping another page. But the URL was configured incorrectly and the page ended up screenscraping itself infinitely, thus causing a stack overflow exception.
The most common error that I have see and "pool crash" is the loop call.
public string sMyText
{
get {return sMyText;}
set {sMyText = value;}
}
Just call the sMyText...
In order to do this, all you need to do is throw any exception (without handling it of course) from outside the context of a request.
For instance, some exception raised on another thread should do it:
protected void Page_Load(object sender, EventArgs e)
{
// Create a thread to throw an exception
var thread = new Thread(() => { throw new ArgumentException(); });
// Start the thread to throw the exception
thread.Start();
// Wait a short while to give the thread time to start and throw
Thread.Sleep(50);
}
More information can be found here in the MS Knowledge Base
Aristos' answer is good. I've also seen it done with a stupid override in the Page life cycle too when someone change the overriden method from OnInit to OnLoad without changing the base call so it recursed round in cirlces through the life cycle: i.e.
protected override void OnLoad(EventArgs e)
{
//some other most likely rubbish code
base.OnInit(e);
}
You could try throwing a ThreadAbortException.
I'm running VS 2008 and .NET 3.5 SP1.
I want to implement hit tracking in an HttpModule in my ASP.NET app. Pretty simple, I thought. However, the BeginRequest event of my HttpModule is firing twice for each page hit. The site is very simple right now...no security, just a bit of database work. Should log one row per page hit. Why is this event firing twice?
Moreover, IHttpModule.BeginRequest actually fires a different number of times for the first page hit when running for the first time (from a closed web browser)...3 times when I'm hitting the DB to provide dynamic data for the page, and only 1 time for pages where the DB isn't hit. It fires 2 times for every page hit after the first one, regardless of whether or not I'm touching the DB.
It's interesting to note that Application_BeginRequest (in Global.asax) is always firing only once.
Here's the code:
using System;
using System.Data;
using System.Data.Common;
using System.Net;
using System.Web;
using BluHeron.BusinessLayer;
using Microsoft.Practices.EnterpriseLibrary.Data.Sql;
namespace BluHeron.HttpModules
{
public class SiteUsageModule : IHttpModule
{
public void Init(HttpApplication httpApp)
{
httpApp.BeginRequest += OnBeginRequest;
}
static void OnBeginRequest(object sender, EventArgs a)
{
UsageLogger.LogSiteUsage(((HttpApplication)sender).Context.Request);
}
public void Dispose()
{ }
}
public static class UsageLogger
{
public static void LogSiteUsage(HttpRequest r)
{
string ipAddress = GetHostAddress(Dns.GetHostAddresses(Dns.GetHostName()));
string browserVersion = r.Browser.Type;
string[] urlChunks = r.RawUrl.Split('/');
string page = urlChunks[urlChunks.GetLength(0)-1];
SqlDatabase db = new SqlDatabase(Common.GetConnectionString());
DbCommand cmd = db.GetStoredProcCommand("LogUsage");
db.AddInParameter(cmd, "IPAddress", SqlDbType.NVarChar, ipAddress);
db.AddInParameter(cmd, "BrowserVersion", SqlDbType.NVarChar, browserVersion);
db.AddInParameter(cmd, "PageName", SqlDbType.NVarChar, page);
db.AddInParameter(cmd, "Notes", SqlDbType.NVarChar, "");
db.ExecuteNonQuery(cmd);
}
private static string GetHostAddress(IPAddress[] addresses)
{
foreach (IPAddress ip in addresses)
{
if (ip.ToString().Length <= 15)
{
return ip.ToString();
}
}
return "";
}
}
}
This might be too late for the answer but can be useful for someone else. I faced with the same problem. BeginRequest event triggered for twice for each request. I debugged the code and realized that the first trigger for actual resource request but the second is result of "favicon.ico" request. At the beginning of BeginRequest event, a simple check for favicon.ico request eliminates second execution of the method.
public void Application_BeginRequest(object sender, EventArgs e) {
HttpApplication app = (HttpApplication)sender;
HttpContext ctx = app.Context;
if (ctx.Request.Path == "/favicon.ico") { return; }
quite late on this, but ran into the same issue. In our case it was due to the anonymous request first that returns the 401 per the RFC. The second request authenticates.
The "Default Document" part of IIS seems to fire a second BeginRequest event.
If you have determined that the Request.Path is the same for the HttpApplication in both event handlers and your URL ends with a slash, try adding a URL Rewrite rule to shortcut the "Default Document" processing.
This is interesting. I removed the reference to the CSS file from the master page and I'm getting fewer repeat hits in the HttpModule for certain browsers (as was suggested), but I'm still getting repeats. I have 6 browsers installed, and I'm getting some variation between them.
For reference, this is the URL I'm plugging in to my browsers for this test:
http://localhost/BluHeron
default.aspx is set as the start page and is indeed returned for the aforementioned URL. I'm using HttpRequest.RawUrl for reporting which page the user hit. Specifically, I'm splitting the RawUrl string and just reporting the last item in the array of strings (see code).
Every single browser is reporting hitting default.aspx, as expected (RawUrl = /BluHeron/default.aspx).
4 of the 6 browsers are also reporting BluHeron (RawUrl = /BluHeron).
3 of the 6 browsers are also recording a blank in the database (RawUrl = /BluHeron/).
There are a couple ways I can get accurate reporting of how many people are hitting which pages.
Select from the database only rows that actually list one of my pages (ignore /BluHeron and blanks)
Just use Application_BeginRequest in the global.asax file, which seems to consistently get called only once per page hit.
Get this figured out.
So, I've got options for getting good reports even with crappy data in the database. I would prefer to understand what's going on here and not to have junk in the database.
Thanks for looking, everyone!
We solved this by using
HttpContext.Current.ApplicationInstance.CompleteRequest();
This should prevent the the twice fire you are seeing.
One possibility is that there are other requests going on that you might not be considering. For example, let's say your ASPX page references some images or CSS files. If those requests go through the ASP.NET pipeline then your module will be called and they'll register as hits.
Also, when you say IHttpModule.BeginRequest, do you mean that in IHttpModule.Init() you are hooking up HttpApplication.BeginRequest? If so then the reason I mention above might still apply.
Disable Browser Link in Visual Studio 2013 and up, which causes the second request.
This occurs when an Application is run from Visual Studio.