We are trying to make a cut over from IIS 6.0 to IIS 8.0 Integrated pool on Windows Server 2012 Standard edition for an application built on ASP.Net Version 4.0. Our web application requests go into a RequestAcquireState ( ASP.Net Session gets locked for concurrent requests working with the same sessionid ) , in IIS 8.0 Integrated pool on the above Windows Server . However this behavior does not show up when we run the same app in Classic mode on IIS 8.0 .
Session is stored InProc.
We can rectify this situation on a Windows Server 2012 Data Center by modifying SessionStateLockedItemPollInterval in registry. However that solution does not work in Windows Server 2012 Standard edition.
This has left us perplexed -
why does an ASP.Net Run time Session issue surface in IIS 8.0 Integrated Pool for an application we have run successfully on previous versions of IIS and classic mode in IIS 8.0 ?
How do we rectify this problem now on Windows Server 2012 Standard edition ?
Thanks, will appreciate if some body can help
IIS 8 comes with .net framwork 4.5 so you may be running into missing the fix http://support.microsoft.com/kb/2828842
Issue 6
Symptoms
When you send many concurrent requests that have the same SessionId to an ASP.NET 4.5 web application, some requests may freeze at the RequestAcquireState stage unexpectedly.
Resolution
After you apply the hotfix, the hotfix makes sure that the EndRequest event will always trigger.
try installing this fix and see if that addressed the issue
Related
I have a relatively simple web application that I am currently porting to asp.net 5. The current version runs under IIS on some Windows 7 and Server 2008 machines.
With the next version of my software I would like to connect a C++ client via SignalR to the web application. The problem is that the current version of the new Signalr-Cpp client only supports SignalR via websockets.
IIS on Windows 7 and Server 2008 does not support websockets, though.
Since a self-hosting solution would be fine for me, my question is:
Is it possible to support Signalr via websockets on Windows 7 / Server 2008 when the web app is self-hosted?
Update:
I would accept
does self hosted signalr require windows server 2012 in order to use websockets? as an answer if there wasn't this small comment by Damian Edwards in the following Tweet by David Fowler which says
although, with v3, websockets in a self-hosted server (like Katana) is possible
Does this change the situation?
Final update
At least with beta 6 it works on Windows 7 when hosting the app with Kestrel and including the middleware Microsoft.AspNet.WebSockets.Server.
It's not possible...
SignalR Supported Platforms
for SignalR to use WebSockets, Windows Server 2012 or Windows 8 is
required
Does self hosted signalr require windows server 2012 in order to use websockets
HTTP.SYS prior to Windows 8/2012 has no built in support for
WebSockets, so although .NET 4.5 contains WebSocket classes, they
won't work unless you are running .NET 4.5+ on Windows 8/2012 and that
will affect self-hosting solutions running in Windows < 8.
UPDATE:
My answer is valid for current release version of SignalR (2.2). Tweets you included (quite old btw) suggest this will be possible in v3 but its not released yet, there is not much info on Internet about changes\features of this release and I even can't find anything about WebSocket support in Katana on Win < 8 in list of Github issues for v3
I installed the SignalR package when our project was running .net 4.0. We since upgraded to 4.5 and I want to support WebSockets. I uninstalled Signal packages and reinstalled SignalR (per this answer). However the SignalR DLL versions (1.1.0/1.1.3) are identical in both cases.
Here is my configuration:
ASP.NET 4.5
IIS 8.0 (Windows Server 2012)
WebSockets feature enabled on the server
A WebSocket supporting browser (latest version of Firefox)
Even though I have all these required things, I still get this:
{"Url":"/signalr","ConnectionToken":"Yy6qHcSMMm4vPl9i3ungxJ5aa2P0SJh4UoU4pelAyFcMud0596UaeB6x8AmhZ2SxW_MPk23QXrKGkwar7LjLLnWlBZx1nokd6LRe96k8D-Oua3kSnKsyDa1RrPTE0n9FyaUO9rK3caLfue20Dmx5UkB9F2TKusPD4PDqQw2","ConnectionId":"b7b00e98-3128-4fbb-ba63-fb16f922f168","KeepAliveTimeout":20.0,"DisconnectTimeout":30.0,"TryWebSockets":false,"WebSocketServerUrl":null,"ProtocolVersion":"1.2"}
I guess the important parts are:
"TryWebSockets":false,"WebSocketServerUrl":null,"ProtocolVersion":"1.2"
Does this mean that I am not using WebSockets? What could I be missing?
Thanks so much.
WebSockets are supported in all major versions of SignalR.
Therefore the question is "what is required for my SignalR application to use WebSockets?"
ASP.NET 4.5
IIS 8.0 (Windows Server 2012 or Windows 8)
WebSockets feature enabled on the server
A WebSocket supporting browser
Now that we've established what is required to have a WebSocket enabled application it seems that your missing the enabling of the WebSockets feature.
To enable WebSockets on your server follow the "Step by Step instructions" here.
Hope this helps!
I know your problem - the same that hit ours!
Your problem is the client you are running from.
The client Windows stack must be > Windows7 to use WebSockets on a
.Net Client
This caught us too!
Browsers aren't affected as they have their own WebSocket stack, but the Windows .Net networking stack doesn't have WebSockets.
Windows 8/Windows 2012 and IIS 8 fixes that.
This is why the SignalR load tester (crank) can't use WebSockets when run on Windows7, only in Windows 2012 (regardless of server)
We since upgraded to 4.5 and I want to support WebSockets.
I'm running Windows 2012 Server, IIS 8, WebSockets feature installed on server and I still get this
Since you are using ASP.NET 4.5, IIS 8 and Windows Server 2012, the problem should be relying on how you migrated the project to .NET framework 4.5 or with the browser. Given that most of the modern web browsers support web sockets, I highly doubt your references are still for the .NET framework 4.0.
Try by creating a new project using .NET framework as 4.5. Simply setting the target using project properties sometimes doesn't update the assemblies.
On my IIS 7.5, my SignalR application always used long polling.
As per my search, IIS 7.5 does not support WebSockets yet.
I hope, I missed some tools or configurations to enable WebSockets in IIS 7.5. Or I didn't?
You cannot use WebSocket on IIS 7.5 (in other words on Windows Server 2008 R2 or Windows 7) because it requires HTTP.sys level changes AFAIK. So, you need IIS 8.0 and Windows Server 2012 or Windows 8 combination to leverage WebSocket. Also, IIS Express 8.0 supports WebSockect, too but you cannot still leverage that if you are on an OS which is lower than Windows 8 or Windows Server 2012.
IIS 8 Express Supports websockets New Features
Windows 7 is considered a Down-Level Operating system and doesn't support Web Sockets. Known Issues and Limitations
Time to upgrade to Windows 8 if you want to support for web-sockets!
Here's a summary of the required setup steps to host on Windows 2008r2 with IIS 7.5:
Update the SignalR application's web.config file to enable "run all managed modules for all requests" (for short, this is the RAMMFAR setting).
Update the web page that uses SignalR to communicate with the server:
Add a reference to the json2.js library.
Add a tag that forces the content to display in a recent browser mode.
Set up a Windows Server 2008r2 with IIS 7.5 as follows:
Install the .NET Framework version that your SignalR application requires.
Create a site and associate it with the appropriate application pool.
Update the Signalr Application's Web.config File
In your SignalR application's web.config file, add the RAMMFAR setting to enable running all managed modules for all requests. This setting was required to get the SignalR sample application running in on Windows 2008r2 and IIS 7.5 in all browsers.
<system.webServer>
<modules runAllManagedModulesForAllRequests="true">
</modules>
</system.webServer>
Update the Web Page that Uses SignalR
In the application web page that uses SignalR to communicate with the server, add the following code.
Add a reference to the json2.js JSON parser library. This script provides a JSON parser for previous browser versions that don't have it. You can add the script in one of two ways:
Add the NuGet package json2.js to your project, and then reference it in your web page:
Or as an alternative, reference json2.js on a CDN:
Add the following tag in the head section of the page. This tag, specifically the IE=edge value, forces Internet Explorer to display content in the most recent version available, rather than earlier modes (such as IE7) which prevent SignalR code from working.
Set up Windows Server 2008r2 and IIS 7.5
As noted, I built the sample SignalR application from the Getting Started with SignalR tutorial on .NET 4. This is a common hosting scenario on Windows 2008r2 and IIS 7.5. The server was a new default default installation of Windows Server 2008r2 and IIS 7.5.
Install the required .NET Framework version. In this case I installed .NET Framework 4.
Create a new site in IIS Manager, and associate the site with an application pool. Use integrated mode application pools, classic mode is not supported for SignalR. For this application I used the ASP.NET v4.0 application pool.
After following the above setup steps, I was able to deploy the .NET Framework 4-based version of the Getting Started with SignalR sample to the server, and it worked perfectly in IE (versions 8, 9, and 10), Chrome, and Firefox even though it was using fallback transport methods (forever frames in IE, and server-sent events in the other browsers). The interesting thing for SignalR developers is that apart from the above steps, I didn't have to change a single line of the SignalR code anywhere in the application to make this work.
This is a simple case but shows that SignalR really does support "automatic fallback" to earlier transport mechanisms when websockets support is not available on the server.
I have recently started to received this message.
Unable to start debugging on the web server.
The IIS worker process for the launched URL is not currently running
Does anyone know what this means?
I created my virtual directory via Properties on the project, and clicking Create Virtual Directory. ANd in IIS I can see it, I run VS 2010 with Admin Privs.
The Application pool in .Net 4.0
Any help really appreciated
Thanks
EDIT
I managed to get it working but its a good workaround really. Basically there was another website setup i.e. Default Website where all my apps goes which was started and running.
And there was another website (which was stopped!) that was for installanywhere.. But it was stopped! ... I removed the site completely and now it works
Can vs 2010 not figure out which one to connect to or something?
I presumed if its stopped then it wouldn't try and connect..
Very confused, Anybody know of alternative work around?
I got the same error message after reinstalling VS2010. In my case all application pools in the IIS where remapped to run 4.0, so VS2010 was unable to figure out which pool to attach its self to during debugging. The solution in my case, was to manually delete few pools and remapping my older pools back to .net 2.0. I finally ended up, only having 2 pools pointing towards .net 4.0 (integrated and classic) and 2 pools running .net 2.0 (integrated and classic).
Hallo,
I am tryiing to migrate an application written with visual studio 2008 from windows XP IIs 6.0 To Windows 7 with IIS 7.5 and I have this problem:
Sometimes when I post the page, the server does not respond and after some minutes i receive e message "Internet explorer can not display a web page"
With IIS 6.0 the application works perfectly.
Please, can you help me ?
Mauro Servi
Try switching the AppPool to Classic .NET mode rather than integrated mode.
You can do this on the Application Pool's Basic Settings in IIS Manager