2

I encountered a bizarre issue that I hadn't previously and I thought I would inquire here to see if anyone had any recommendations.

Currently, my application has an area to create a new "recording" (which uses a Flash module within a new window to record audio) and when the recording is finish, the user submits the form and all of the audio data is posted to my controller.

This process can range in duration depending on the size of the audio, so the window will remain open until the uploading is finish and then it closes.

The problem occurs during the upload process, if the user uploads a recording and while it is uploading, attempts to open a new window (which is populated with the "Create Recording" view) and the loading of the new window contents stalls until the upload is complete.

The entire process works fine if I open up multiple windows for the Create Recording prior to actually uploading one of them, however if I start uploading one and then attempt to open a new window then it will "wait" on the upload operation to finish before populating the new window contents.

Rion Williams
  • 74,820
  • 37
  • 200
  • 327
  • Does it matter which browser you use? Some browsers have simultaneous connection limits. – Erik Funkenbusch Oct 10 '12 at 13:48
  • I believe that it has been all of the browsers that I have tested (IE and Chrome). It's just strange it would "wait" for the controller action to finish before beginning to render the view. – Rion Williams Oct 10 '12 at 13:51
  • Not that strange. When the action finishes, so too does the web connection. If it's not the browser, then I don't know what the problem is. MVC uses a thread pool to manage connections, and there are usually at least 10 threads in the pool, so 2 simultaneous blocked connections shouldn't cause the problem. You must have some other blocking mechanism going on. – Erik Funkenbusch Oct 10 '12 at 13:54
  • Thanks Mystere, I'll look into the connections issue, although I don't think that would be the reason, as you had mentioned just two connections wouldn't cause this issue. – Rion Williams Oct 10 '12 at 13:57

1 Answers1

4

I think you're running into an issue with sessions.

Anything that is served while there is an active session and that can modify it (ie any .Net request, but not images/css/etc) will get an exclusive lock on the session object until the request completes. Other requests which can access the session will be queued until the lock is freed.

More information here

It's possible to work around by indicating that certain requests only need read-only access to the session-state. See the answers of the linked Q for full details.

There's an implementation of a custom session-state module here which may speed things up considerably. It works by caching the session info in a hash table in memory and then telling the framework that the session access has been completed.

Note that there are potential issues with this approach in that if 2 pages modify the session at approximately the same time, it may result in a race condition to see which modification gets preserved - so only do it if you fully understand the implications.

Community
  • 1
  • 1
Basic
  • 26,321
  • 24
  • 115
  • 201
  • Thanks Basic. I actually JUST finished implementing a fix for it, I'll probably eventually migrate everything over to use a separate controller for all the AJAX / Asynchronous calls. The [SessionState(SessionStateBehavior.ReadOnly)] attribute fixed everything up for now. – Rion Williams Oct 10 '12 at 17:48
  • Glad I could help. That one's a bit of a gotcha when you've got something long-running – Basic Oct 10 '12 at 18:39