[Looking for Charlie's main web site?]

Monitoring ColdFusion web server connectors, more on Tomcat 'Status Workers'

Note: This blog post is from 2015. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.
If you're running CF 10 or above, there was a very interesting post on the Adobe CF blog, from July 19 2015, entitled, Configuring Status Worker in Connectors. The Adobe blog post title may not have caught your attention, but it's about setting up a lightweight and built-in Tomcat monitoring feature for observing the status of the Tomcat web server connector.

You may want to consider enabling it, but I would add some caveats and observations that I share below. Note that it's really quite easy to enable, and DOES NOT require a restart of CF (only of your web server, or technically in IIS, a recycling of the application pool/s--a web site restart is not enough) to take effect.

[....Continue Reading....]

Thanks for fleshing this out, Charlie. Most helpful!
# Posted By Paul | 8/3/15 12:04 PM
And thank you, Paul, for that. (Sorry for the delay in acknowledging that.)
# Posted By charlie arehart | 8/21/15 9:27 AM
Charlie, this might seem like a stupid question, but I want to make sure I get this right because we are having some issues with our services. On the timeout settings, in their blog, Adobe says: Connection pool timeout: - This setting determines the timeout value (in seconds) for idle connections in connection pool. This value must be in sync with the connectionTimeout attribute of your AJP connector in Tomcat's server.xml.

I guess our setting is not correct because the timeout setting in wsconfig's configuration files is set to 60 seconds and I see connectionTimeout="20000" in the server.xml file. Should I set connectionTimeout="60000" in the server.xml file to match wsconfig? Or should I change the value in wsconfig configuration files to be 20 seconds instead of 60? Or does it even matter? Thanks
# Posted By Pawel | 11/25/15 9:37 AM
Hi, Pawel. I will say that at least according to Adobe, you would want to set the times equal, and yep, the one file is in seconds and the other is in milliseconds. So you ought to change one or the other. (Anything is better than the default, of 0, which means there is no timeout, and idle connection threads can live indefinitely, which can be bad under certain circumstances.)

Now, I say above that "according to Adobe" you should make the change, but you ask if it "really matters", and in fact I would note that many people have by mistake made the change only to the property file of the connector and not remembered to change the server.xml. Or they may make the change in both, but then "reconfigure" their connector and forget to put the timeout change back in the property file.

In both cases, I have not found it to be the cause of any significant problem, myself. Could it cause a problem, if they are not in sync? I suppose. I'm just saying that I don't think the implications are well-understood. It would be something useful to better understand, for sure, for everyone's sake.

But bottom line for you: just make them be in sync. :-)
# Posted By Charlie Arehart | 12/2/15 11:21 AM
Thanks Charlie, this is very helpful. I ended up going with the below configuration after I re-read Adobe's article and updated our documentation to check the server.xml setting after reconfiguring the connectors (I didn't even think about that before your comment).

<Connector protocol="HTTP/1.1" port="#" redirectPort="#" maxThreads="500" connectionTimeout="60000"/>

And the connectors:
# Posted By Pawel | 12/2/15 11:27 AM
Yep, that has the timeouts in sync. Just be sure to check that workers.properties file in all the connector folders (the numbered ones under config\wsconfig), as the timeout in all of them should be the same, to be in sync with that server.xml setting.

That said, the other settings, like max reuse and pool size may well vary between the connectors (or not), and I would note that no one can say from the outside whether the particular values one chooses would be "good ones" or not, as there are too many variables.

Again, someday I want to blog about that with more observations. :-) For now, you're at least set with respect to the timeouts being in sync between this connector and CF.
# Posted By Charlie Arehart | 12/2/15 11:37 AM
Great. Thanks again
# Posted By Pawel | 12/2/15 11:44 AM
Anybody have a copy of the Adobe Blog entry referred to hear? Looks like it was removed at some point.
# Posted By Trevor | 3/12/18 1:52 PM
Yes, Trevor. You can find it in the web archive here:


And since that will likely break in this blog software's reformatting of the URL, here's a bitly link:


For more on that archive, and how to leverage it for a question like this, see my post here:


As for this blog post being missing from the Adobe blog, that is indeed very odd. I don't know of it being intentional. I will ask some folks to see if they may reply about this (or put it back. They may do neither, of course).
# Posted By Charlie Arehart | 3/12/18 1:55 PM
FWIW, the Adobe blog post was restored finally today.
# Posted By Charlie Arehart | 5/16/18 10:40 PM
Here is an article detailing connector tuning in CF 11, which includes details on Server.xml and workers profile settings.


We came across this when researching a problem with scheduled task timeouts, when we would see these errors via Fusion Reactor;

java.net.SocketTimeoutException: Read timed out


private native int socketRead0(final FileDescriptor p0, final byte[] p1, final int p2, final int p3, final int p4) throws IOException;

We hope that modifying the connectionTimeout setting in Server.xml and the worker.cfusion.connection_pool_timeout setting in the workers profile.
# Posted By Scott Taylor | 8/3/18 2:38 PM
Hi, Scott. Thanks for the offer of the info, but note that I had already pointed to that blog post of theirs in this entry above (twice, in fact).

As for the read timeout you are seeing, well I doubt those will be fixed by tweaking the connection_timeout. That is about how long an IDLE (no longer used) connection can remain available in the connection pool. That will NOT affect a RUNNING request.

Now, as I also point out in the post, these are in fact facets of TOMCAT connector tuning, and I point to the docs on that. And one of the pages there is just about timeouts: https://tomcat.apach... There are various timeouts that could be affecting you--but I will note that most default to 0 and so should NOT lead to timeouts waiting for long requests.

As for your saying that the request you make (that fails) is a CF scheduled task, well that then opens up still MORE possibilities, as your issue could be about the caller (CF in this case) or the server you're calling (you don't say if it's a CF page on your own server), and the web server that fronts that.

All of those could have an impact on what may timeout, and how that would relay back to your sched task as a "read timeout".

If you may be interested in help to get to the bottom of this, that's the kind of consulting I do and I can often solve problems (remotely) in less than an hour that might have plagued folks for days, weeks, or months. For more, see the consulting page on my site here (including my satisfaction guarantee, my rates, my approach, and more).

But if you figure it out on your own (or we might together), do share what you learned, for others to learn from.
# Posted By Charlie Arehart | 8/3/18 3:35 PM
We are currently running CF2016 with Apache 2.4.18.
We updated Apache to 2.4.37 and it runs successfully.
Problem is users are now unable to access the page with a 400 error that IE was able to connect to the web server but there is now a problem with the address.
# Posted By Todd Lance | 1/18/19 1:58 PM
Todd, sorry to hear of your challenge, but to be clear, what you are dealing with has nothing to do with the topic of this post (the "status worker" monitor feature for the Tomcat web server connector that CF uses).

And this blog post is not therefore an appropriate place to have a back and forth on your challenge and getting to its solution. (And FWIW, I don't have any immediate suggestion, but I would ask many questions to guide you to the problem and solution.)

Instead, you could ask this as a question on the Adobe CF portal (https://coldfusion.a...) where I and others do watch for such questions and try to help.

Or if you prefer direct (and more immediate) assistance I should be able to help you resolve this quickly via my remote troubleshooting consulting. More on my rates, approach, and satisfaction guarantee at https://www.carehart...
# Posted By charlie arehart | 1/18/19 4:17 PM
Copyright ©2020 Charlie Arehart
Carehart Logo
BlogCFC was created by Raymond Camden. This blog is running version 5.005.
(Want to validate the html in this page?)

Managed Hosting Services provided by
Managed Dedicated Hosting