Closed brunoborges closed 1 year ago
Let's review with @mnriem this one.
For each of the common application servers I would recommend to review their clustering / HA guides and/or their cloud deployment guides. Note that I do not considered static variables our concern as that would open a huge can of worms. But common caching dependencies could be tackled.
If we concentrate on Tomcat for now, it looks like the clustering configuration is on the server.xml
file (which is located in the runtime itself, not in the code). The only piece of information located in the code is the <distributable/>
element in the web.xml
file. And the rule already exists in WindUp, so it's just a matter of overriding it ;o)
@agoncal can you fill in on this one please?
Because both Azure App Service and Azure Kubernetes service can scale in and out as load changes, storing state in-process does not usually work well. Issues related to in-process state won’t immediately prevent apps from working in Azure, but they should be identified so that developers can proactively prepare for scaling events. In-process state can take many forms.
One common pattern indicating stateful-ness is ASP.NET configuration. Use of the
<sessionState />
element in web.config’ssystem.Web
section without a mode property or with mode set toInProc
orStateServer
should be flagged for review. TheInProc
mode (or no mode specification) indicates that session state is being stored in-proc whereas StateServer indicates that state is stored in an external process which also does not work well in Azure App Service or Azure Kubernetes Service.Another possible source of statefulness is static collections. It is difficult to know, though, whether data stored in such fields is needed across multiple replicas. To reduce noise, it is probably best to begin by not flagging static collection fields unless we hear customer feedback indicating these fields should be identified.
Existing WindUp Rules