I'm working on an ASP.NET 4.0 Web Forms project, after a break of about 5 years, and I'm confused about the submit behaviour.
In the click event of a button, I sleep the thread so that I can click the submit button multiple times.
From what I can tell, ASP.NET is preventing the click event being called more than once. Is this true?
BTW: I've turned off javascript for this test.
"ASP.NET is preventing the click event being called more than once. Is this true?"
No, actually what is happening to you is that your events are blocked by the lock of the session. (What session is on asp.net, is a module on asp.net that can keeps data for each user that visit the site)
So when you make a submit, and the page is running this submit, and then you make a second one before the first one replay, actually the second one is waiting the first to finish and unlock the session.
To make a test and prove that the session is locking your request, turn off the session and try again your test.
relative:
Web app blocked while processing another web app on sharing same session
What perfmon counters are useful for identifying ASP.NET bottlenecks?
Replacing ASP.Net's session entirely
Trying to make Web Method Asynchronous
No, As you are making your main thread sleep it causes the session to get blocked which prevents it from processing any further requests. Hence it gives that effect. If you have an independent task which can be done without web request and response, then you can perform it in separate thread. This will not block your process.
Related
I have a basic Asp.Net application, to test a problem I want two instances of IE calling an asp.net page, I want the first to block (Thread.Sleep) and the second to proceed, hence I have code like this:
private static bool firstOne = true;
...
if (firstOne)
{
firstOne = false;
System.Threading.Thread.Sleep(10000);
}
What I'm actually seeing is both pages wait for the sleep to finish, it's as if there is a single thread servicing both.
NB I don't have the debugger attached nor any breakpoints
This is on my work pc, default machine.config and web.config. Nothing unusual has been configured.
This isn't something I normally have to do so i could easily be missing something obvious here
Any ideas?
The reason is the asp.net session module that locks the request until is finished.
Also the thread that you place on sleep is the requested thread and not a new one. If you make a new one and left the page return, then the new thread will live and die alone without affect your session. The session is lock on request the page, and unlock when the page is finished.
The session is lock entire each request of the user to synchronize them. To avoid it you simply turn it off for that page, or use handlers that not use sessions by default.
You can also make your totally custom session that handle that case.
If you wondering if this is good, that session is lock your user, yes is good for starting sites because is really helps you to synchronize the user actions. If session not lock your user, you must do that by your self with mutexes, and on each action of your user, eg when you insert something on a database.
One similar question:
Web app blocked while processing another web app on sharing same session
I created an asp.net page for waiting ajax. I have one page creating something that takes 30 seconds. On every step I change a session value.
I have another page for ajax, returning the session value for showing the percentage of creation. But, I dont know why, my ajax page awaits the end of the creation of my first page. So I only get the 100% at the end.
Maybe it's because I use VS development server and not IIS server. If this is the problem, can I change settings of the development server for asynchrone execution?
Or is it something else?
WebForms are not ideal for asynchronous operations.
Add SignalR to your project and use a Hub to push status data back to your page to update the current state of the process you are running Asynchronously.
An example of a technique to perform this type of asynchronous notification is covered in my blog post titled "A Guide to using ASP.Net SignalR with RadNotifications"
Don't use ASP.Net session state to do that. It has an implicit reader/writer lock around it, meaning your other call is probably blocking until your process finishes. You can try storing your status in a database or the cache, but it would probably be better to redesign the interaction.
I need to handle requested file missing with complex longworking logic.
I can do it in Application_Error but not sure if it is async itself or not?
Will this handler block other users for all time, if it take for example 5 minutes or more to work?
The Application_Error its take part of the page processing, is called from the page that you load, so the question is if the Page or the handler is asynchronous its self.
It is, if you not use session, and of course if you do not use other synchronization locks, like mutex, or database open/read/write
Why is that ? because session is locking the full processing, look at this question/answer:
call aspx page to return an image randomly slow
ASP.NET Server does not process pages asynchronously
Trying to make Web Method Asynchronous
Web app blocked while processing another web app on sharing same session
What perfmon counters are useful for identifying ASP.NET bottlenecks?
Replacing ASP.Net's session entirely
File upload and result pooling kills ASP.NET web app
So to make it simple, the Application_Error is just a static function call but is connected to the processing of the page or the handler. Make sure that the page or the handler are not block each other, and all is ok.
From the other hand, a processing of 5 minutes, if you try to make 500 of them together and not place them on a query list, you may have other problems.
I just make a simple test, place System.Threading.Thread.Sleep(20000); on Application_Error and make an error, and continues to load other pages, and works.
I have ab asp.net form which does a few minutes of processing on postback(button click).I Know this is not ideal but I cannot run this process in an async thread as it uses a control reportviewer which is in Reqd only mode in non primary threads.
Given this limitation as the process is going on I would like to show the status at the client. For this I can fire off Ajax requests to the server to obtain processing status.But since the ASP.NET primary thread for the session is busy rendering the report using the reportviewer control the Ajax requests simply wait until all processing is over. Is there any way to periodically relinquish and regain control of primary thread .This we can allow it to reply to any ajax requests.
I have been researching this problem for a while now.All I need is to render a set of reports in background using the ReportViewer control and provide feedback at client
thanks
That makes no sense. New AJAX calls from the browser can and will be serviced by any of the available threads in the thread pool.
How are you posting the form? You would have to start the process with an AJAX request to generate the reports or else the browser will lock up waiting for the return from a normal form post. This would prohibit additional client side calls to be made to check status.
I created a simple web application where a search form is filled out, submit
button clicked, and a message is sent with the search parameters via
nServiceBus. I also have a handler in the same project that picks up the message
(from the same queue). For some reason, the web server process blocks until
after the message is picked up, is there any reason for this? I set a breakpoint
in the message handler and it breaks before the request finishes... locking the
browser until I allow the code to continue. I would expect control to return to
the browser regardless of when the handler gets fired...
Thanks,
D.Niemeyer
Are you using .RegisterWebCallback() in your code, as that is what is responsible for preventing ASP.NET to complete the HTTP call?
This was answered in the nServiceBus forum. This is a phenomenon caused by having the debugger attached, which stops all threads if a breakpoint is hit before the response is returned. Placing a sleep in the handler demonstrates this.