Weird behavior in user control, tick event isn't accessed
Hi,
I have made an user control containing a registration form, the user control is inserted in the pages through a macro. In the uer control I have a longrunning process that takes up to 3 minutes, to not bore the visitor to death I have put this in another thread and while it's running I'm displaying a progressbar and information about where in the progress the script is. This is done by having an updatepanel and a timer and a asp:Literal that is updated on "Tick", the progress text is saved in a session. This works in a regular webform like a charm, no problem at all, this webform has the same look, jquery-scripts, css etc as the production system. But when I take this user control and put it into umbraco and execute it the tick event never happens, the updatepanel is updated but the tick event isn't accessed. I don't have any clue on why at all.
if (Session["CreateProcessActive"] != null && (Session["CreateProcessActive"].ToString().Equals("0") || Session["CreateProcessActive"].ToString().Equals("ERROR"))) { Session["Done"] ="1"; tmrCreateAccount.Enabled = false; Response.Redirect(Request.Url.AbsolutePath+"?action=done"); } } protected void CreateCustomer() { //this process can take up to 180 seconds Session["CreateProcessActive"] = "1"; Session["CreateProcessText"] = "Creating account"; // Doing a lot of stuff... Session["CreateProcessText"] = "Doing something"; // Doing a lot of stuff... Session["CreateProcessText"] = "Doing anotherthing"; // Doing a lot of stuff... Session["CreateProcessText"] = "Done, redirecting"; Session["CreateProcessActive"] = "0"; }
I know that this code isn't optimal, but after 500 tests and problem solving to find this issue this is what I have for the moment :) Any ideas why the tick event isn't accessed? I'm using latest version of umbraco on IIS7,5
It's very strange that accessing to the Session object from inside the child thread works properly. As a rule of thumb you should never ever try to call any web-specific objects (like HttpContext, HttpSession, HttpApplicationState, etc) from outside the thread of the http request execution. If you need some way to communicate between a child thread and an asp.net thread then you'd better look for something outside an http context - something like a database, a file on the disk or even a static variable.
That's the worst about such a pattern - it may seem to work :-) A couple years ago I had big time hard days tracking such a bug in legacy code. As it turned out later they read an uploaded file straight from HttpRequest using a child thread. And it seemed to work - but right untill the size of the file was less then the httpRuntime/requestLengthDiskThreshold (omg I even didn't know about this setting before)...
I added some additional code and noticed that it actually is updated, must be the second thread that doesn't update the session.
So back to drawing and use a database...
The weird part is that the second thread is executed and actually reads sessions from the first/main thread but setting/updateing sessions from that thread doesn't work
And there's yet another very important thing to keep in mind. All code in a child thread always should be wrapped with try-catch. Any unhandled exeption in a child thread lays down the whole IIS application pool - it's a notorious feature that emerged since .NET 2.0 (a breaking change in background thread behaviour).
Weird behavior in user control, tick event isn't accessed
Hi,
I have made an user control containing a registration form, the user control is inserted in the pages through a macro. In the uer control I have a longrunning process that takes up to 3 minutes, to not bore the visitor to death I have put this in another thread and while it's running I'm displaying a progressbar and information about where in the progress the script is. This is done by having an updatepanel and a timer and a asp:Literal that is updated on "Tick", the progress text is saved in a session. This works in a regular webform like a charm, no problem at all, this webform has the same look, jquery-scripts, css etc as the production system. But when I take this user control and put it into umbraco and execute it the tick event never happens, the updatepanel is updated but the tick event isn't accessed. I don't have any clue on why at all.
The header of the page contains:
The user control contains:
The code behind
I know that this code isn't optimal, but after 500 tests and problem solving to find this issue this is what I have for the moment :)
Any ideas why the tick event isn't accessed? I'm using latest version of umbraco on IIS7,5
Should add that I only have one form-tag on the page.
It's very strange that accessing to the Session object from inside the child thread works properly. As a rule of thumb you should never ever try to call any web-specific objects (like HttpContext, HttpSession, HttpApplicationState, etc) from outside the thread of the http request execution. If you need some way to communicate between a child thread and an asp.net thread then you'd better look for something outside an http context - something like a database, a file on the disk or even a static variable.
Yes I know, but it works in the dev environment, and for now it's only a test. But the problem remains, the tick event isn't fired at all
That's the worst about such a pattern - it may seem to work :-) A couple years ago I had big time hard days tracking such a bug in legacy code. As it turned out later they read an uploaded file straight from HttpRequest using a child thread. And it seemed to work - but right untill the size of the file was less then the httpRuntime/requestLengthDiskThreshold (omg I even didn't know about this setting before)...
I added some additional code and noticed that it actually is updated, must be the second thread that doesn't update the session.
So back to drawing and use a database...
The weird part is that the second thread is executed and actually reads sessions from the first/main thread but setting/updateing sessions from that thread doesn't work
And there's yet another very important thing to keep in mind. All code in a child thread always should be wrapped with try-catch. Any unhandled exeption in a child thread lays down the whole IIS application pool - it's a notorious feature that emerged since .NET 2.0 (a breaking change in background thread behaviour).
I'll have that in mind :)
Thanks, you made my day!
is working on a reply...