101
Replies
Actually, it’s off by a letter. 
Emailing you a reply with that and more.
/charlie
Doh, never mind. It was my copy/paste of it that missed a letter. Again, email to you directly with more, to come.
/charlie
Thanks for the kind regards.
As for your finding that recycling the app pool helps (“Once we restart the app pool, those requests timeout and new requests come in and process correctly”), that would tell me something very interesting:
Recall how I noted that your stack traces showed the hanging requests waiting on a CFIMAGE read action, which was resulting in an http request?
I am willing to bet now that you will find that the source of the cfimage was a URL on your own server (whether for a CF page or perhaps even a static image, PDF, or whatever).
And I’d be willing to bet that THOSE requests (the ones your CFIMAGEs were waiting on) were then stacked up in IIS. And so yes, recycling the app pool(s) cleared THOSE, and that then allowed the hanging requests in CF (the CFIMAGE waiting on those) to now end (or timeout, if you have times set).
I’d really now suspect you may have an issue with the web server connector tuning. (It’s great to hear that you see the dll is updated. And I’m assuming you checked ALL your numbered folders under coldfusion10\config\wsconfig). So now the question is had you considered or done any tuning of those, tweaking the workers.properties file settings in each of those numbered folders?
For instance, do you at least have the connection_pool_timeout set? Many find that just setting that to 60 is a huge help. (To be clear, this has NOTHING TO DO WITH how long pages in CF run. It’s how long idle connections in the connector remain living.) Sadly, it’s not set by default, and so there is no timeout and they can live forever (idle), and eventually the connector runs out of threads, though due to other matters related to the settings for connection_pool_size (also not set but which defaults to 250) and max_reuse_connections (which is set initially to 250).
If you have more than one site, and whether you have one connector or more, then you need to do some tuning, otherwise (for a variety of reasons), any one site could grab all the threads leaving none for other sites. And again, this could absolutely be exacerbated by a spider or bot crawling one or more sites on your server, leading to this starvation in one or more of the sites.
Fortunately, Adobe has a blog post on this. There was one for CF10 in 2012, and another in 2014 for CF11. I know you’re on 10, but read the one for CF11 as it has much more info, and the concepts and defaults are exactly the same. And you’ll read there that there are also two corresponding changes needed in your CF instance’s server.xml (coldfusion10\cfusion\runtime\conf, or replacing cfusion with your instancename if on Enterprise with multiple instances).
I will admit that the blog post leaves some things to be desired, and you’ll see that both the CF10 and CF11 posts have many comments (a few dozen each) from folks (including myself) who tried to draw out more details and clarifications from Adobe. For now, it’s about all we have. See
http://blogs.coldfusion.com/post.cfm/coldfusion-11-iis-connector-tuning
And then note that they subsequently came out with a post to talk about adding a measure of monitoring for the connector, in the form of the Tomcat “Status Worker” which one can easily enable (no restart of CF required). I blogged about that with a little more intro and pointing to the Adobe post, here:
http://www.carehart.org/blog/client/index.cfm/2015/8/3/more_on_tomcat_status_worker
Finally, those perhaps reading along and new to the whole issue (alluded to in the last two notes) about the need to update your web server connector, I had also blogged about that here:
http://www.carehart.org/blog/client/index.cfm/2013/9/13/why_you_must_update_cf10_webserver_connector
Hope that’s helpful.
/charlie
AdChoices