Wednesday, March 21, 2012

90 seconds delay for posting back to the server when user clicks the abortButton

Hi,

In my application, I have an UpdateProgress control with an abortButton. I hook the Onclick attribute of this button to a server-side method.

When the application does not contain a global.asax file, all is working perfectly: When the user click on the abortButton, it posts back immediately.

But, when the application contains a global.asax file, there is a delay of approximatively 90 seconds between the user's click of the abortButton and the execution of the method in the server-side.

Here's a little exemple how to reproduce the problem:

aspx page:

<%

@dotnet.itags.org.PageLanguage="C#"AutoEventWireup="true"CodeFile="Default.aspx.cs"Inherits="_Default" %>
<%@dotnet.itags.org.RegisterAssembly="Microsoft.Web.Atlas"Namespace="Microsoft.Web.UI"TagPrefix="cc1" %>
<!DOCTYPEhtmlPUBLIC"-//W3C//DTD XHTML 1.0 Transitional//EN""http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<htmlxmlns="http://www.w3.org/1999/xhtml"><headrunat="server">
<title>Untitled Page</title>
</head>
<body>
<formid="form1"runat="server">
<div>
<cc1:ScriptManagerID="ScriptManager1"runat="server"EnablePartialRendering="True">
</cc1:ScriptManager>
</div>
<cc1:UpdatePanelID="UpdatePanel1"runat="server">
<ContentTemplate>
<asp:ButtonID="Button1"runat="server"OnClick="Button1_Click"Text="Button"/>
<asp:LabelID="lblResultat"runat="server"Text="Label"></asp:Label>
</ContentTemplate>
</cc1:UpdatePanel>
<cc1:UpdateProgressID="UpdateProgress1"runat="server">
<ProgressTemplate>
Contacting server... <br/><br/>
<asp:buttonid="abortButton"runat="server"OnClick="abortButton_ServerClick"Text="Abort Request"/>
</ProgressTemplate>
</cc1:UpdateProgress>
</form>
</body>

Code behind:

using

System;
using System.Data;
using System.Configuration;
using System.Web;
using System.Web.Security;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;
using System.Web.UI.HtmlControls;
using System.Threading;
using System.ComponentModel;
using System.Net;

public

partialclass_Default : System.Web.UI.Page
{
privateEventWaitHandle ewhWait =newEventWaitHandle(false,EventResetMode.ManualReset);

protectedvoid Page_Load(object sender,EventArgs e)
{
}

protectedvoid Button1_Click(object sender,EventArgs e)
{
Thread thread =newThread(newThreadStart(ThreadLong));
thread.Start();
ewhWait.WaitOne();
lblResultat.Text ="End of lengthy method";
}

publicvoid ThreadLong()
{
Thread.Sleep(100000);
ewhWait.Set();
}

protectedvoid abortButton_ServerClick(object sender,EventArgs e)
{
ewhWait.Set();
}
}

Global.asax

<%

@dotnet.itags.org.ApplicationLanguage="C#" %>
<scriptrunat="server">
void Application_Start(object sender,EventArgs e)
{
// Code that runs on application startup
}void Application_End(object sender,EventArgs e)
{
// Code that runs on application shutdown
}void Application_Error(object sender,EventArgs e)
{
// Code that runs when an unhandled error occurs
}void Session_Start(object sender,EventArgs e)
{
// Code that runs when a new session is started
}void Session_End(object sender,EventArgs e)
{
// Code that runs when a session ends.
// Note: The Session_End event is raised only when the sessionstate mode
// is set to InProc in the Web.config file. If session mode is set to StateServer
// or SQLServer, the event is not raised.
}
</script>

To Reproduce the problem:

1- put a breakpoint in theabortButton_ServerClick method
2- Execute the application and clickButton1
3- clickAbort Request
4- after 90 seconds, the application breaks.
5- Remove Global.asax from the solution
6- Execute the application and clickButton1
7- clickAbort Request
8- the application breaks immediately.

This delay appends also under different conditions; I explained the Global.asax case because it is the easiest to reproduce.

Is there someone knowing the reason of this behavior?

How can I force a postback of the abortButton ?

Thank you for any input .

Well it looks like you have gone to quite a bit of trouble just to get an abortButton cancel the current requests. I hate to tell you but there is a much easier way to abort requests. Atlas has a special button called abortButton (go figure). So basically the atlas framework looks for a button event with the id of abortButton. You don't have to create some custom method to cancel the request the atlas framework handles it, and it works great. Below is all you have to put into the UpdateProgress template and you will be set. At least now you have some really cool code to shutdown events :). By the way when you press the button it doesn't force a postback it just ends the request.

<

inputid="abortButton"type="button"runat="server"value="Stop"/
Have fun!

JoeWeb


Hi JoeWeb.

Thanks for your quick reply.

I am using the Atlas abortButton.
I don't think it's matter if it is a "input type=button" or a asp:button, both are translate by Atlas like this :

<button id="UpdateProgress1_abortButton">
<click>
<invokeMethod target="_PageRequestManager" method="abortPostBack" />
</click>
</button>

But just to be sure, I try this button

<input id="abortButton" runat="server" type="button" value="Stop" onclick="AbortRequest()" />

and in the javascript AbortRequest() I call the server via anICallbackEventHandler method.

Atlas is doing a great job cancelling the request on the client side. The problem is that it does not cancel it on the server-side, the methode is still running.
You can verify that by placing a breakpoint in a long request. Even if you cancel it, the breakpoint will eventually be hit.

In my application, if somebody cancel the request I have some cleanup to do. So, if somebody cancels with the abortButton, the server must be inform in some way.

I also notice that if you cancel a request and re-submit it immediately, Atlas waits 90 seconds before posting it to the server.


Don't know what to tell you then. The application we have using atlas handles about 15 million records in a database for tons and tons of customers and it handles requests just fine. Haven't had any problems with it taking longer to send a request right after aborting it. We serve alot of data back and forth and it handles the request no problem. Sorry, don't know what to tell you.

Good luck.

JoeWeb


I finally pin-pointed the problem with the Atlas abort button.

I was wrong when I said that there was no request to the server when the Abort Button is clicked.
I traced Global.asax and I found out that the BeginRequest event is triggered.

The problem is with the creation of the handler between the ResolveRequestCache event and the AcquireRequestState event; this operation takes almost two minutes to complete.

I don't know why it tooks so long. For other request than the Abort Button it's very fast.

Am I the only one to have this problem ?

No comments:

Post a Comment