Might be worth knowing what values you have in AJP section of CF runtime conf server.xml EG:
<Connector port="8012" redirectPort="8447" protocol="AJP/1.3" tomcatAuthentication="false" maxThreads="900" connectionTimeout="60000"/>
Sometimes folks have benefited but using tomcat native ajp-apr rather than ajp-bio as you currently have.
Sometimes over a few days up-time the problem can be Java. Do you know if the memory variables for Server Settings > Java and JVM > Maximum JVM Heap Size and in > JVM Arguments XX:MaxPermSize (CF10 so I am guessing Java 7 rather than Java 8 which would be XX:MaxMetaspaceSize) are configured well?
Thanks for responding! We have the following in our server.xml
<Connector protocol="AJP/1.3" port="8012" redirectPort="8445" maxThreads="900" connectionTimeout="60000" tomcatAuthentication="false"></Connector>
I think are configuration for the JVM is good, we tuned it awhile back to resolve issues with Coldfusion hanging, but the current issues is just the failure of the application pool, Coldfusion is still fine when the application pool is restarted.
Our minimum and maximum JVM heap size is 3000mb and our MaxPermSize is 400mb. We are actually on Java 8.
"Sometimes folks have benefited but using tomcat native ajp-apr rather than ajp-bio as you currently have."
I'm not familiar with using the native ajp-apr instead of the ajp=bio, but will look into this now.
I think your issue is a little different as we don't have those errors in our isapi_redirect.log, but thanks for sharing your issue in case they were the same. Hoping we both find solutions to our recent issues quickly.
One other thing to consider with tomcat threads and pools, it can be a good idea to specify an initial setting. EG considering your max setting:
server.xml AJP section -
If you are interested to try tomcat native ajp-apr copy 64 bit tcnative-1.dll to CF\cfusion\lib then restart CF.
Check content of coldfusion-error.log for presence of ajp type.
I guess like you the CF Java end is ok since you recycle the application pool to overcome issue. Of note since you are using Java 8 that consumes Metaspace not PermSize. Having PermSize present is a syntax error which is not "stop the world". Metaspace if not defined should auto size but in doing so can lead to full garbage collection to size up to a new "watermark". Java reminders full GC is pause effect. Having
said all that I doubt a full GC pause will be causing the overall problem then again hard to say with certainty.
Thanks again for the suggestions for resolving this issue. I'm going to look into and test setting initial values for the Tomcat threads and pool size.
Good point about using Metaspace and not PermSize with Java 8. Would I define Metaspace similar to how I've set MaxPermSize previously?
I tend to find if you know a Java 7 value for MaxPermSize worked well use same value for Java 8 Metaspace. It can be a good idea to configure an initial value. EG syntax:
HTH again, Carl.
Thanks Carl. I'm going to make these jvm changes and connector configuration changes and then update our connectors one more time. I'm hoping that the iaspi_redirect.log provides some insight into the issue the next time our application pool stops responding. I've been thinking this was really an IIS issue, as restarting the application pool always resolves the issue, but it does appear to be an issue with the connector that causes the initial problem with the application pool.