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.
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.
Anil Ruia
Software Design Engineer
IIS Core Server
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.
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.
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.
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()
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)
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.
Response.Flush()
Response.End()
Even in some blog i had read to remove flush statment but it didn't work. even end statement give me same error(An error occurred while communicating with the remote host. The error code is 0x80070057).
So, If any one having idea related to this issue. Please please inform me.
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.
jb
5 Posts
Re: The I/O operation has been aborted because of either a thread exit or an application request
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.
anilr
2343 Posts
Microsoft
Re: The I/O operation has been aborted because of either a thread exit or an application request
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.
Software Design Engineer
IIS Core Server
jb
5 Posts
Re: The I/O operation has been aborted because of either a thread exit or an application request
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.
jb
5 Posts
Re: The I/O operation has been aborted because of either a thread exit or an application request
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.
whitesites
7 Posts
Re: The I/O operation has been aborted because of either a thread exit or an application request
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,
fixing The remote host closed the connection. The error code is 0x80070057
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()
MattDuguid
34 Posts
Re: The I/O operation has been aborted because of either a thread exit or an application request
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)
ErrorCode 2147943395
gunjan.gandh...
4 Posts
Re: The I/O operation has been aborted because of either a thread exit or an application request
Oct 22, 2009 05:38 AM|LINK
Hi All,
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.
Response.Flush()
Response.End()
Even in some blog i had read to remove flush statment but it didn't work. even end statement give me same error(An error occurred while communicating with the remote host. The error code is 0x80070057).So, If any one having idea related to this issue. Please please inform me.
I required it ASAP.
Thanks all in advance.
Gunjan
whitesites
7 Posts
Re: The I/O operation has been aborted because of either a thread exit or an application request
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
w3wp.exe using too much memory and resources
gunjan.gandh...
4 Posts
Re: The I/O operation has been aborted because of either a thread exit or an application request
Oct 22, 2009 06:51 AM|LINK
hi whitesites,
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.
whitesites
7 Posts
Re: The I/O operation has been aborted because of either a thread exit or an application request
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?