CF websockets

@mattf48248714 , your description of the issue is exemplary. Even before I finished reading it for the first time, I had an idea of what could be the problem. I immediately thought of resource exhaustion. But I needed to look further into it.

First of all,  the IIS settings in workers.properties (worker.wss.connection_pool_size, worker.wss.connection_pool_timeout, worker.wss.max_reuse_connections) could matter. As you will see in a moment, one of your settings is problematic. But it seems like something else is causing the problem you're seeing (that is, clients connecting instantly but failing to subscribe later). 

The IIS settings control the AJP connector between IIS and ColdFusion. They determine, for example, how many AJP connections can be open and reused. So, for the overall traffic and general health of your server, you will need to use the optimal IIS settings.

Suggestions:

• A connection_pool_size of 20 seems far too low. Set it to the same value as max_reuse_connections, namely, 5000.
• Make sure the settings in workers.propoerties match the corresponding settings in server.xml. 
  Therefore,  
  worker.wss.max_reuse_connections=5000 / maxthreads="5000";
  worker.wss.connection_pool_timeout=60 / connectionTimeout="60000"

See https://www.petefreitag.com/blog/tuning-tomcat-iis-connectors/ 

Nevertheless, I now think that resource exhaustion is ithe main cause of the issue. 5000 - 10 000, that's a lot of concurrent connections. That is likely to exhaust resources as follows:

• If clients connect or disconnect frequently or are idle for too long, the websocket server may not properly clean up old, defunct subscriptions or sockets. If so, then, sooner or later,  websocket's channel list will get polluted with these invalid or "ghost" subscribers.

• ColdFusion's websocket implementation lacks explicit settings with which to fine-tune the configuration of sockets. Think of settings such as heartbeat or keepalive, Their absence can have consequences: "zombie" connections.
  On the client side, browsers, firewalls and proxies can silently drop TCP connections if these idle too long. ColdFusion wouldn't always notice that. It means your websocket channel may think clients are still subscribed, but they aren't really reachable anymore.
  This was reported on ColdFusion 2016 in 2018. Adobe did acknowledge it is a bug, but its status is still "To Fix". See https://tracker.adobe.com/#/view/CF-4203142 

Suggestions:

• Reduce socketTimeout: Since your system is not hitting any (memory or CPU) resource limits, chances are that there are a lot of idle connections. Therefore, you might want to decrease the socketTimeout, so idle connections are terminated more quickly.
  You can do so by editing the file /lib/neo-websocket.xml. Use a value much lower than the default 300, say, 120.  
• Experiment with an increased framesize and with a decreased framesize: FrameSize controls the maximum size of each websocket frame that can be sent or received over a websocket connection. Each frame represents a chunk of data transmitted over the connection.
  The default value in ColdFusion's websocket is 1024 KB. It is the setting Max Data Size on the page Server Settings > Websockets in the ColdFusion Administrator. Equivalently, it is the element maxFrameSize in /lib/neo-websocket.xml.
  
  Larger frame sizes allow the websocket to handle larger payloads in one go. If your application has large websocket messages, then the connection issue you're seeing might be due to fragmentation and reassembly of too many messages that exceed the framesize. If so, increasing the framesize might help.
  
  Granted, increasing the frameSize may lead to higher memory usage, as large frames need to be buffered, transmitted, and processed. However, as you have said, you aren't hitting any memory limits. So it is worth experimenting by increasing the framesize. Say, to 4096 KB.
  
  On the other hand, since you're experiencing connection failures, decreasing the framesize can help. That is because smaller frames reduce the chance of overloading the traffic with too much data at once. In so doing, smaller frames are more efficient, especially when dealing with a large number of concurrent users, as in your situation. The one big assumption is that most of the messages are small. 
  If indeed so, then experiment by decreasing the framesize to, say, 256 KB.

I know this is old but did you ever find a solution to this?

I am encountering this same issue with websockets, cf2021, latest patch w/IIS 

I am aware that your post was from 2021, but can you tell us what patch of 2018 you're on?
Thank you.

We're having the same issue. It requires restart to work for a period of time (most daily) and we don't know where the setting is to fix this restart issue. Please share if you found a solution for this.

Matt, while I wish I could propose some single tweak that would help, there are just too many variables. What I would say is that with a combination of better monitoring of things, as well as close assessment of those various configuration settings (to make sure there's not an issue that's unclear for what you have shared), it SHOULD be possible both to understand what's causing the failing updates/channel communication, and then what setting needs to be tweaked (whether in the connector and its config, the proxy and its config, CF, IIS, the JVM, or perhaps even something else).

If you're at all interested in a helping hand to assess all that, see my carehart.org/consulting page. I hate to drop that as the only solution I can offer, but for now it is. Perhaps soemonee else will have another suggestion if you prefer to wait for that. But if you want it solved, either we will or you won't pay for any of my time you don't find valuable.