0

On our server running Server 2008 R2 using IIS 7.5 we have one of our sites that stops responding to requests and eventually produces 503 errors. The site is also running Coldfusion 10. These failures are occurring every few days.

When the problem occurs I start seeing client_reset errors for requests to the site in the httperr log file. These will continue and request made to the site will not respond. No error is displayed the request just hangs. After about ten minutes I will see 503 2 Disabled errors in the httperr log file and attempts to reach the site will also return 503 errors to the end user.

During our attempts to resolve this issue we have also noticed queue is full errors in the httperr log and have increased the Application Pool Queue Length from 1000 to 3000 over time. We have also increased the appConcurrentRequestLimit from 5000 to 10000.

Our workers.properties file for the IIS Connector has the following settings:

worker.cfusion.type=ajp13
worker.cfusion.host=localhost
worker.cfusion.port=8012
worker.cfusion.max_reuse_connections=900
worker.cfusion.connection_pool_size=900
worker.cfusion.connection_pool_timeout=60 

When we look at the successful requests in the general IIS log leading up to an application pool failure we will typically see high requests in short amount of time from a single or similar ip addresses. These appear to be bots of some type, most likely comment spam bots.

At this point, I'm unsure if this is a problem with the Connecter between Coldfusion and IIS, an IIS tuning issue, or a code issue that is causing the client_reset errors to start and the eventual failure of the application pool.

What would be causing the client reset errors and the eventual failure of the application pool? Stopping and starting the application pool in question resolves the issue.

1 Answer 1

0

We just had similar issues, where the App Pool would randomly start and need to be restarted... detailed at this bug - https://bugbase.adobe.com/index.cfm?event=bug&id=3490112

the latest CF10 update 18 includes a fix for this, if your problem is the same one. So far this update (And redoing all the connectors after updating) has solved the problem for us, only time will tell if it ever comes back.

3
  • Did you application pool show as still running, but not respond to requests? Do you mind sharing your worker.properties settings you are currently using? We are on update 18, but still having random application pool failures that I can't resolve. Jan 11, 2016 at 18:53
  • In our case the application pool showed as stopped, not still running. Here's our worker.properties from that instance worker.list=instance worker.instance.type=ajp13 worker.instance.host=localhost worker.instance.port=8012 worker.instance.max_reuse_connections=400 worker.instance.connection_pool_size=2250 worker.instance.connection_pool_timeout=60
    – Don W
    Jan 21, 2016 at 14:31
  • I think ours shows as still running only because I have disabled rapid fail protection, otherwise it would show as stopped. I appreciate the feedback and I do think that we are getting closer. Jan 22, 2016 at 15:29

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .