We got a few cases where customers were selecting a minimum resource App Service plan when deploying company communicator. The original/standard CC deployment uses a S2/Medium App Service plan by default, but we got a few cases where a smaller plan was being selected during deployment.

We all need to understand that the reduction in cost generates consequences to the application. Without any of the new features, we see Azure Functions taking 100% of the CPU with S1/Small, and when we have processes taking 100% of the CPU, other enhancements just don’t have enough resources to run.

We got an interesting case where the App Service that hosts the webservices was just crashing with a message saying “An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full.”

I strongly recommend leaving the default configuration for the App Service plan. Actually, even consider an increase in capacity if the new features, specially the message read and button tracking features are important for you.

Those tracking mechanisms leverage a set of webservices hosted on the App Service, and if they don’t have enough resources to run, exceptions will be generated and you may have a crash of the App Service.

To protect the App Service in those cases, and for those of you that still want to run CC in a non-recommended configuration (S1/Small) we implemented a few things in the new 4.40 version.

  1. Implemented the App Service config variable DisableReadTracking to disable message read tracking. That is because we have some customers that installed CC in a S1/Small instance and that config doesn’t support the additional load imposed by the read tracking mechanism.
  2. The read tracking code is now inside a try/catch to reduce the risk of crashing the App Service in resource depletion situations caused by running CC in S1/small App Service plans.

By default the read tracking is enabled as the DisableReadTracking configuration variable is inexistent. You can decide to disable the whole read tracking system by going to the App Service configuration and creating a new configuration setting named DisableReadTracking with the true value.

We also implemented a better exception handling to reduce the risk of crashing the App Service. But keep in mind that during resource depletion situations, we have no control and you may find an App Service crash, that will require a manual restart.

Please consider running CC in a better plan if that is important to you.

Cristiano.

Disclaimer – The information contained in this blog post doesn’t represent the official Microsoft guidance or best practices. It is just the view of the author on current alternatives, implementations and workarounds for common issues and/or business needs. Please refer to official Microsoft documentation and evaluate carefully any steps, code or procedures documented herein. The author doesn’t offer any warranty. Use this information at your own risk.