IIS 7 & IIS 8
The I/O operation has been aborted because of either a thread exit or...
Last post Oct 31, 2012 07:53 AM by runningfree
Aug 27, 2009 03:58 PM|LINK
I called support and unfortunately all they were able to find was a hotfix for kb275030 (which doesn't seem to be the same as bug 275030). It is in Czech. Web searches seem to indicate something about exchange or windows 2000 sp2.
Aug 27, 2009 04:49 PM|LINK
The hotfix for the bug that tmarq mentions has not yet been built or released.
That said, I don't think your problem is at all related to the bug that tmarq mentioned (which only results in a spurious event log message/exception) - in your case, it seems like you are reading client request entity after the session has been locked and
this is timing out after 2 mins and during those 2 mins, all other requests using that session are blocked - the only way to fix that would be to read the request entity before the OnAcquireRequestState event using a HttpModule rather than in your handler/aspx
page like you are currently doing. Also, like you mentioned, you may be able to disable auto session locking and then manually lock it in your code after reading the request entity.
Aug 27, 2009 05:13 PM|LINK
Your understanding is exactly correct. tmarq emailed me and he too was concerned that the fix wouldn't fix this problem.
I think I'm going to ask our developers to try reading the post body (or do something that causes it to be read) in the Application_OnBeginRequest handler in global.asax. I'm hoping this is early enough in the pipeline to be before OnAcquireRequestState.
It looks like it should be early enough from the "Professional IIS7" book. I would like to avoid a custom HTTPModule just because we haven't done one before.
I hadn't thought of getting AcquireRequestState because it is so early in the process. Thanks for pushing me in that direction.
Let me know if you see a flaw in this plan. I'll let you/everyone know if it works.
Aug 27, 2009 08:21 PM|LINK
We have decided not to read the post body in the OnBeginRequest event. This would probably slow down all requests a tiny bit as it would wait for the post body before starting the pipeline (instead of starting processing while the post comes in).
Instead we think we are going to set EnableSessionState=ReadOnly (which will be a hack at first). We will actually still be writing to the session on these pages and this will only work with inproc session storage. We haven't implemented and tested this
fully yet, but it appears to work. Eventually we will confine our session updates to a few pages and mark those pages as session updateable pages. Then the "readonly" setting won't be a hack, the pages really will be readonly.
Coming from another architecture into this one, this all seems a bit odd. The session object in other environments is not threadsafe just like the application object isn't in asp.net. This gives the developer the chance to screw themselves up, but it also
lets them deal with (avoid) issues like this.
Sep 13, 2009 12:50 AM|LINK
I was getting this error about 50 times a day on a website that does about 35K impressions daily. Something I read on another site was to make sure any web control that doesn't need to postback has enableviewstate set to false. This will greatly reduce
the size of your viewstate. Since doing this I am only get 15 errors of this kind each day. So it helped by was not the silver bullet I was looking for.
I have created a post on my blog discussing this,
If anyone has any suggestions let me know. All my other websites are running fine except this one. Seems to be some problem with .IIS7WorkerRequest.ExplicitFlush()
Sep 17, 2009 04:35 AM|LINK
We set enableviewstate to false at site level via the web.config and still get this error. I believe you may have a slightly different problem to us as your error is 0x80070057 and ours is 0x800703e3.
We sre still trying to track this down...
The I/O operation has been aborted because of either a thread exit or an application request. (0x800703e3)
Oct 22, 2009 05:38 AM|LINK
I had read all the comments on this blog, Even i having same error with the following enviorment.
--> Window server 2008 64bit, .Net 3.5 with SP1, IIS7
In my web application, it give me error when following line excute.
So, If any one having idea related to this issue. Please please inform me.
I required it ASAP.
Thanks all in advance.
Oct 22, 2009 05:51 AM|LINK
Let me take a wild guess,
You are getting this error and your W3WP.exe is really big
Disable the viewstate on your label controls.
Once I did this the problem web away.
I wrote a blog entry on some possible solutions
Oct 22, 2009 06:51 AM|LINK
Thanks for your response, But let me tell you one thing, i had check my W3WP process and it is not so much big which close the session.
Enve i had check that befor executing flush command IsCilentConnect property give me true value and after executing flush statment it give me false value.
This code is perfectlly run under Window server 2003, .net 3.5sp1, iis6.
Oct 22, 2009 06:58 AM|LINK
What is your script trying to do?
Why are you explicitly using flush?
Did you check your Label Controls?