8

Under heavy load or when using jQuery's ajax abort function, we see requests build up in IIS to the point where no-one can connect and the entire site hangs, forcing a recycle.

A similar post from 3 years ago had a similar issue with .NET 4.5 and IIS 7.5 but Microsoft have stated this was fixed in 4.5.1 and released a patch for 4.5.

This problem on Windows Server 2012R2 using IIS 8 when trying to use State Server and even more so when using State Server on development machines running Windows 10 and IIS10. The patch cannot be installed on any of these machines as the installer is blocked by the presence of 4.5.1. Changing to In Proc reduces the occurrence of the issue but does not solve it completely.

This dead thread from this year on the IIS forum had a few others with the same issue but with no resolution. I have also tried setting the UploadReadAheadSize to 0 as suggested somewhere else but that did nothing to resolve the problem.

Has anyone else experienced and/or found a solution to this? Any input would be greatly appreciated.

Community
  • 1
  • 1
Dan Def
  • 1,836
  • 2
  • 21
  • 39
  • I'm also having the same problem. When I find a solution/fix I will post it here. Have you figured it out already? – JonHendrix Jan 31 '17 at 12:53
  • @Tweek we've been using 4.5.2 for a while now and none of my team has reported it so far. Which version are you using? – Dan Def Jan 31 '17 at 20:05
  • We are running on 4.5.2 - still having this issue. It happens most of the time on some classic (old) aspx pages without any jquery/ajax calls. – JonHendrix Feb 02 '17 at 07:50
  • That's the opposite of what we saw. The problem would manifest itself if we made an AJAX call, cancelled it before it completed and then tried to make another call. I'm wondering whether updating to 4.6.x will solve the problem for you? – Dan Def Feb 02 '17 at 21:35
  • @DanDef, were you able to find any resolution to this issue? Did upgrading to .net 4.6.x fix the issue? – Babak Naffas May 02 '17 at 22:13
  • @BabakNaffas unfortunately we haven't had the opportunity to upgrade to 4.6.x yet. I can confirm that we are still seeing the problem with 4.5.2 now though. – Dan Def May 03 '17 at 07:43
  • Same here. If/when we get a chance to try 4.6.x, I'll let you know. – Babak Naffas May 03 '17 at 23:22
  • Same issue on 4.7.02053. Was anyone able to solve it? – Anton Jan 03 '18 at 10:23
  • 2
    @DanDef have you had any luck with this issue? – Justin Mar 22 '18 at 18:11
  • It's been a while now, but were any of you that experienced this problem using custom modules at all? – Dan Def May 06 '21 at 16:31

1 Answers1

0

The problem we had appeared to have been caused by someone implementing the suggestion in this post Can I access session state from an HTTPModule?.

This appears to trick the SessionStateModule into thinking it needs to load SessionState even if the handler that will eventually be executed isn't marked with IRequiresSessionState by temporarily swapping it for one that is. Once SessionState is loaded the handler is swapped back to the original. I suspect, but have not proved, that if the request is cancelled the SessionStateModule is not releasing the locks because the handler "in play" at the time is not marked with IRequiresSessionState; hence there is no clean up to do.

Removing the module and marking the handlers that didn't therefore need IRequiresSessionState before made the problem go away.

Dan Def
  • 1,836
  • 2
  • 21
  • 39