Fixing the WebSocket Protocol Support issue when upgrading to EPiServer UI 9.4.0

The release notes for Update 100 also states that in CMS.UI 9.4, Websockets is required on the server because of the Instant UI updates in the Projects feature.

(AFAIK, Projects is still disabled by default until it's activated in Admin > Settings, so it's a bit strange that Websockets is required up front.)

Good writeup nonetheless!

I saw it was a beta feature, so if your account isn't in the beta admin group will you even see the message?

FWIW, I just got done adding the websocket protocol. :)

Yes it was beta feature I got the message for user belonging to the groups webadmins and webeditors and administrators for an alloy website upgraded to the latest and also for the upgraded website from 8.x to this version.

And I have not enabled the projects features but was planning to for the alloy website since it will be a demo for a customer :) 

Thx for sharing. That will be something a lot of us will run into and scratch our head about I think :)

I had this issue too, and found out it pays to read release notes for major versions. So if you're going to run a CMS 9 site on older versions of IIS, disable WebSockets

http://world.episerver.com/documentation/Items/Upgrading/EPiServer-CMS/9/Breaking-changes/

"Note: System Requirements have changed for CMS 9. Windows Server 2008/2008 R2 and Windows 7 are no longer supported due to missing websocket support."

The most annoying thing is that if you're using DXC where using Edgecast CDN is required, then WebSockets isn't supported (by Edgecast) so you will need to turn off WebSockets to get rid of the error message.

Well done, EPiServer.

@Petra, that could be circumvented if you set up your DXC environment with different domain for edit, and not route that through EdgeCast. Funnily enough, that would also circumvent the issues with upload file size that EdgeCast has.

Sure, that would be a workaround for live sites. In development or testing where that wouldnt be setup yet it's quite annoying though. I'm just fascinated that a feature is released (in beta and on by default) that's not supported fully by the services that DXC uses.

I'm entirely with you, I think it's unacceptable. However, a separate edit domain could be acheived in DXC Integration environments as well, it would just mean an extra strange domain to remember, instead of a regular strange domain :)

Haha, yeah. Another weird URL, just what we need :)

Hi,

Adding some information to the thread.

We are working on resolving the issue with websockets in DXC as we speak. We have earlier conducted a proof of concept that was successful and we are working on ticking off the final boxes right now. This will be introduced as soon as possible and we will let you know.

We will make sure to coordinate these type of releases going forward.

Please feel free to e-mail me or support if you have questions.

-Daniel

Hi,

The features included in CMS UI 9.4 are not in beta, we missed removing the beta from the names before releasing, which is why WebSockets is enabled by default in the UI.

We are using the underlying socket implementation inside the Projects gadget even though Project Mode may not be enabled. But the system will still work (except you will get no live updates in the projects components) if sockets are disabled on the server.

And as Daniel said we will make sure to coordinate these types of releases better in the future.

-Magnus

I must say I am abit concerned about the choice of websockets for this feature. This makes it very hard to make high availability sites as websockets have to make a persistent connection to a specific server, meaning rolling updgrades of servers with no downtime for the endusers is going to be extremely hard.

That is unless the client script using websockets has built in retry/reconnection functionality, is this in place? Also how does this affect servers that are not load balanced with sticky load balancing(imho you should never use that because of HA requirements) but using round robin or least connection load balancing? 

This also puts a new requirement for the load balancers or reverse proxies in use not to mention that not all CDNs support websockets.

Some of our clients require very high uptime SLA requirements so you don't just take all servers in a farm offline for code deploy or windows patches, you do rolling upgrades for zero downtime for the end user if at all possbile.

That was a great comment. Could @episerver or @magnus respond to this maybe? I will try to ping Magnus on skype so that we get an answer :)

If you're running on Azure there's an On/Off switch for Web sockets under General -> Application settings for your Web app.

Hi Tomas,
Let's see if I can help with some of the questions:

1. The client does have reconnection functionality. It will try to reconnect at an increasing interval, warn about trying to reconnect after three attempts and finally give up after eight.

2. Should be ok with any load balancing strategy as long as long as remote events and session state is setup among the load balanced servers.

3. Yes, whatever is in front of the servers needs to be able to handle websockets.

/Erik

And an update to answer 2... Session state is NOT needed for the websocket functionality. So no change in setup is needed for this.

/Erik

Enyoing this thread!

There is one way of finding out if your infrastructure is supporting WebSocket before an upgrade.

http://www.websocket.org/echo.html

Ours did not =( so it will be  FTW untill I can convince IT dep to allow it to pass through the proxy.

/Daniel

@Daniel Österhof: Can you provide an update to the resolution you mentioned for the DxC?

We would prefer to not have to disable features of the product in order to use the hosting provided by EPiServer.

Thanks!

Chris

@Petra Liljecrantz: I'm very interested in your comment mentioning a file upload size when using Edgecast CDN via DxC. Can you provide more information? I cannot find any documented limitations online.

Thanks!

My app is writing socket errors to log even though I set in web.config. How can I make epi stop trying?