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.

In this post, I discuss the tool, elaborating on a post that Adobe offered about it last month (July 2015: for future readers, note that the feature remains essentially unchanged and just as potentially valuable in 2025, when I have tweaked this post just a bit, adding a table of contents and changing the order of some topics).

You may well want to consider enabling the "Status Worker" feature, which the Adobe post shows is easily done. Still, in this post I elaborate on some observations and caveats not covered in that brief post, which you will want to consider before enabling or trying to understand the output of the tool.

As background, news of this tool was shared originally in a very interesting post on the Adobe CF blog, from July 19 2015, entitled, Configuring Status Worker in Connectors. Even if you noticed it, the post title may not have caught your attention, but it's an important topic. If you've not yet read the Adobe blog entry, go check it out and then come back here for the additional observations I share, some of which could be very important.

Here are the topics I cover here in my post:

• What is the web server connector and why should I care to monitor it?
  • This "Status Worker" is a Tomcat feature, not an Adobe creation
  • This Status Worker is not available with the Boncode connector
  • This Status Worker is not available if you forward/proxy requests
• Easy setup, but some configuration challenges to beware
  • Don't leave it editable and/or unsecured
  • Beware if you DO use the EDIT feature, site(s) may hangup momentarily
  • You need to configure Status Worker for each connector you've enabled
• Some challenges to beware in USING the tool
  • Beware: Status Worker reports only for the site where you're viewing it
  • Beware: Status Worker only reflects status since any connector restart
  • Status Worker info is helpful, but may not help solve all connection problems
• Some other thoughts
  • Status Worker can help manage Tomcat/CF clusters
  • Monitoring the connector with JMX

(Update in 2018: The original 2015 Adobe post that I refer to, written by Chinoy, was somehow lost in the move to Adobe's portal in 2017. The URL offered in my opening paragraphs is in fact a republication in 2018 of that original post, shown as being by Saurav, who recovered it. The content is otherwise identical, but for the sake of completeness/posterity you can still find the original post at the archive.org version from 2016.)

What is the web server connector and why should I care to monitor it?

It may help some readers to explain that the web server connector is the traditional means by which requests get from your web server (IIS or Apache) to CF. In CF9 and earlier, it was a JRun connector. In CF10 and above, it's a Tomcat connector. Specifically the Tomcat AJP connector. (And for the sake of completeness, Adobe briefly even offered an AJP connector for nginx, but that was not supported for long.)

While for most folks the web server connector is something they may never know or worry about, for others it was something they had to care a lot about when initially moving to CF10 or 11 (for reasons outlined in comments in other Adobe blog posts, like ColdFusion 11 IIS Connector Tuning.) Thankfully, many of those initial issues have been resolved by various improvements Adobe has made over the years since.

Anyway, this Tomcat "Status Worker" is lightweight monitoring feature could be helpful for everyone running CF to consider. I show here a portion of its report, as enabled on my own site just now. Some may recognize its output as looking a LOT like the Apache mod_status output.

(Let me also clarify, at the outset, that this Status Worker is not at all a substitute for a full-fledged request monitoring tool, like the CF Enterprise Server Monitor, FusionReactor, or SeeFusion. It does NOT list all running requests, like those do. As you can see, the report on the right does not list running requests, though it does list at least a count of running requests. I show one in the image, indicated by the "busy" count showing "1", discussed further below.)

This "Status Worker" is a Tomcat feature, not an Adobe creation

As another point of clarification, and as Chinoy does indicate, this "Status Worker" is not an Adobe creation. It's a Tomcat-provided feature, supporting the Tomcat-provided AJP connector (which Adobe enables when running CF's "web server configuration" tool). The Status Worker feature is just not something that Adobe sets up for us by default nor have they mentioned before that 2015 post above. You certainly could have found it yourself (and find out more about it) in the Tomcat docs for it, which Chinoy helpfully points to.

This Status Worker is not available with the Boncode connector

Note as well that if you're running Lucee/Railo, you more likely use the BonCode connector. While that uses the same AJP protocol to connect IIS and Lucee/Tomcat, it is in fact an ALTERNATIVE to the Tomcat AJP connector, and as such this Tomcat Status Worker feature does not apply to you: you have no workers.properties file in which to configure the Status Worker, and Boncode doesn't offer any support of the Status Worker.

But if you may have instead configured your connection between IIS and Lucee/Tomcat to use the Tomcat-provided connector, then yes this Status Worker WILL be an option you can enable, as discussed here.

This Status Worker is not available if you forward/proxy requests

I'll note as well that if you may have your Apache (or IIS or nginx or any web server) configured to instead "forward" requests directly to the built-in Tomcat web server (which CF provides by default at port 8500 and Lucee provides by default at port 8080), then you are also NOT using an AJP connector. You're formally having your web server reverse-proxy requests to that tomcat web server (the "http connector" configuration line in the server.xml file).

And as such this Status Worker feature is not available to you, either. You would want to turn your attention to any available monitoring that your web server itself offers. Again, Apache has mod_status I mentioned above, while IIS has its "worker processes" feature and perfmon metrics, and so on.

With this introduction out of the way, let's move on to matters related to configuring the tool, some of which are not obvious.

Easy setup, but some configuration challenges to beware

As I noted above, setup of the connector is easy, and it's covered in the Adobe blog post, so I won't repeat those steps here. Note that it DOES NOT even require a restart of CF (only a reload of Apache or restart of IIS--though technically in IIS, you could simply recycle the IIS application pool/s for your site/s: a web site restart is NOT enough.)

Still, even upon reading either just the Adobe blog, or indeed those Tomcat docs it refers to, you may find some challenges when trying to implement and understand the Status Worker, despite Chinoy's helpful explanation. I wanted to elaborate on some of those matters here.

Don't leave it editable and/or unsecured

If this will be a server on the internet (or indeed, accessible to an intranet where someone could want to cause trouble), then please heed his warning to enable the read_only=True option when enabling/configuring it.

If you do not, then by default ANYONE who reads the Adobe blog post could then try their proposed /cf/status URL against your server and (assuming you have configured it per those steps) they will be able to not only MONITOR your web server connector status info but more important they will be able to change the settings in your web server connector.

Some may note that "these changes don't change the configuration permanently, they only last until the next restart of the connector", and that is true. Still, someone could cause trouble for you changing some of the connector settings on-they-fly while your server is running.

As the Tomcat docs note, another option to consider is to use web server configuration features (IIS, Apache, etc.) to control who can access this /cf/status URL. For instance, with either Apache or IIS, it would be easy to use their available URL Rewrite feature, to look for a pattern /cf/status*, and "reject" the request if the {REMOTE_ADDR} "does not match" a given IP address (and you can repeat that condition again to name another remote_addr).

(And of course, you could use a different URL than /cf/status, but beware the oft-made warning about "security by obscurity".)

The wiser plan is to ALWAYS set this read_only option on, by default, if enabling this Status Worker. If you need to make changes, change them in the config files and restart the worker (restart Apache or IIS, or in IIS you could also just recycle the app pool associated with the connector to restart it.)

Beware if you DO use the EDIT feature, site(s) may hangup momentarily

If you MAY tempted to use the "edit" feature in the Status Worker, do note that some Status Worker operations (especially that edit operation, to display/modify editable connector options discussed above) may LOCK UP the connector briefly. This affects ALL requests using the connector, including from other users.

So if you see your Status Worker web request hanging up (which could be a few seconds), beware it may not be only YOUR browser (making that request) which is hung up: it may be the entire connector that's hung up, and other requests made by other users on the same connector will be hung up, again perhaps only momentarily.

I've only observed this with the initial display of that "edit" operation in the web interface, and only for at most a few seconds. Still, do beware. It's easy to think it was "only your request" that was hungup. I confirmed this while observing multiple concurrent requests.

You need to configure Status Worker for each connector you've enabled

Note that this Status Worker feature is indeed enabled PER CONNECTOR (and I discuss later how you view it PER WEB SITE).

But my point here is that if you have configured more than one connector (if you have multiple numbered folders under [coldfusion]\config\wsconfig), and you want to have a Status Worker working for each, then you need to specify this configuration (in the files Chinoy showed) within each connector folder. If you get a 404 error trying to access the /cf/status URL, this is probably your problem. (You can get that also, though, if you just forgot to restart the web server/recycle the app pool for the site in question.)

The way you would get to each Status Worker is to visit the site's URL by whatever way your web server's configuration defines a binding (for a domain/ip address and/or port), and then add the status URL you setup (like /cf/status).

Again, I'll have more to say on this in a moment, but if you had multiple web sites sharing one or multiple connectors, you would use the /cf/status URL to view the monitor for each site's domain/ip/port to see the status of connections from the web server to CF for that site. (Note that it's totally ok for the worker name and indeed the URL pattern to be the same in multiple connectors. Connectors are independent from each other.)

BTW, the "port" that he refers to (for accessing the Status Worker display) is indeed the port (if any) that you would use for requests made to your web site which uses the connector configured to be monitored. It does NOT refer to the AJP port, like 8012 or 8013 or 8014, as you may see listed in the workers.properties file. Nor does it refer to ColdFusion's internal web server port, like 8500, if you may have that enabled. This AJP web server connector has nothing to do with using CF's internal web server. It's only one of the ways that your external web server, like IIS or Apache, can be connected to CF.

Some challenges to beware in USING the tool

So with all that introduction and configuration out of the way, let's move on to possible challenges you may face when trying to use and interpret what the tool can show you.

Beware: Status Worker reports only for the site where you're viewing it

This is very important to understand, and not at all obvious from the Adobe post, the Tomcat docs, or even from merely using the tool: each Status Worker report will only report on connections to THAT one specific site through which you're viewing it. It does NOT report on requests going through any another site and/or connector.

So yes, this means that for you to know the status of connections against ALL your sites you'd need to run this tool AGAINST ALL YOUR SITES, one at a time. Frustrating, I agree. Even so, the tool has value for any particular site you may be interested in inspecting.

Being able to see all the connector values for all sites at once could be valuable, because you may be having a problem with one site's use of connections and not another! Another benefit would be to know how many connections are being used across ALL sites at one time, as would be counted against the total connection_pool_size for that connector, and the maxthreads defined in CF.

Sadly, there is no mechanism in this Tomcat-provided tool to get one interface that reports for ALL web sites. Nor is there any logging of this connection info, at all. (There is perhaps value in leveraging JMX metrics. I've not explored that. I discuss it further below. The closest built-in option we have is the CF metrics log, which I also discuss separately below.)

[I will note, though, that if you have your web site bindings setup so that a given web site does respond to multiple domains and/or subdomains, then you only need to view the Status Worker for one of those sites, as it's per SITE not per domain within a site, technically. And FWIW, the Status Worker does not reflect any requests made using ColdFusion's built-in web server, such as may have enabled to process requests for the CF Admin, for instance.]

As for a means to automatically monitor the Status Worker, I will also note that there is an option in the Status Worker to cause its output to be rendered as XML. One could create a mechanism to track that information programmatically, though it's beyond the scope of this post to explore that further.

Beware: Status Worker only reflects status since any connector restart

I have come to observe that the information displayed in the Status Worker report is REFRESHED (wiped out, starts over) if the connector is restarted. In the case of IIS, that's if the application pool that underlies the site in question gets restarted/recycled. The numbers are of course also reset if the web server (IIS, Apache) is itself restarted.

In the case of IIS, this is especially important since application pools can be be recycled not only manually (such as by right-clicking on one in the application pools list), but they can recycle on their own. For instance, by default app pools recycle after 20 minutes of inactivity, and every 1740 minutes (every 29 hours)! That's a MS-implemented default that you can change, of course.

My point is that if you are viewing the output of the Status Worker, it is NOT necessarily cumulative over a very long period of time. It could reflect only minutes worth of information, even though CF has not itself restarted.

Status Worker info is helpful, but may not help solve all connection problems

The information reported by this Status Worker mechanism may be helpful for some problems, so do check it out. But it's not clear to me if it will help us all to understand/resolve problems related to proper configuration of the connector, as have been discussed in the Adobe blog entries like the one I mentioned before, at ColdFusion 11 IIS Connector Tuning.

My observation of things is that the "count" info (such as the counts of how many requests are "busy", or "connected") are the same information that can be seen in the metrics.log (new in CF10 and above), assuming it's properly configured. (I've done a separate post on that, where I report how the port in the CF Admin Debugging Output page setting for this should be the connector/AJP port, at least if most requests to CF do connect through an external web server. Sadly, the CF Admin defaults to using CF's built-in web server port, 8500.)

Anyway, I can report that the "busy" value (in the Status Worker report, and the metrics.log) does reflect the number of currently running requests (if any), if you do have long-running CFML requests (running in that site and connector). That's interesting, but remember again that this only reflects requests in THAT site and connector. If you have requests running against OTHER sites and/or connectors, this total will NOT equal the TOTAL number of running requests in CF (which IS reported in the metrics log, CFSTAT, and tools like the CF Enterprise Server Monitor, FusionReactor, and SeeFusion).

The "connected" ("Con") value (in both) is more interesting. It seems to reflect the count of connections, which do indeed live on beyond the life of a request (and can be terminated after being inactive for a while by changing the connection_pool_timeout feature discussed in the Adobe IIS connector tuning blog entry mentioned above, or again are terminated if the web server or app pool in IIS is recycled.) That number may be helpful for knowing when the number of connections is being starved (also discussed in that IIS connector tuning blog entry, but again it's a challenge that this worker only reports for the one site against which you're running it.)

The "state" value may be useful, if it's ever showing other than "OK". The legend indicates that we may want to watch out for a state value of "OK (busy)" (all connections busy), or perhaps also "ERR" (error, with possible sub-"states"), or maybe even "OK (idle)" (no requests handled). More on these in the Tomcat Status Worker reference docs.

Just remember, again, as discussed above, the info in this Status Worker report is only for requests against THAT site and reflects information since the web server (and/or IIS app pool underlying that site) was last restarted.

Some other thoughts

Status Worker can help manage Tomcat/CF clusters

While my focus here has been on using it for monitoring and troubleshooting, it's worth noting that if your connector has been configured for load balancing, then the Status Worker also both provides additional information about the cluster but also adds features (in the web UI) to manage the cluster, including taking instances (workers) out of the cluster. Again, this is beyond the scope of this post, but see the discussion of options like "edit" and "recover" in the aforementioned Tomcat Status Worker reference docs.

Monitoring the connector with JMX

Before concluding, let me note that another tool which could help with monitoring the connectors (and other connections) is the underlying Tomcat JMX metrics. I hope to someday do a post on them, and how to get access to them, and hopefully also how to log them to watch changes in monitored values over time.

Or again, as I noted, web servers offer there own monitoring features which might be better than nothing at all. Of course, when it comes to monitoring what's going on INSIDE CF (or Lucee), nothing beats a monitor that is running inside them, whether FusionReactor or otherwise.

Conclusion

So the Status Worker is an interesting Tomcat feature, which CF users may want to leverage for monitoring the web server connector, which handles communications between the web server and CF. It can help track how the connector is being used, and it may help understand configuration issues regarding the connector.

I'd love to hear if others have success using the Status Worker, and for sure if I get to work with someone with the problem and we discover something using the Status Worker, I'll update here or create a new post.

Hope all that's helpful.

For more content like this from Charlie Arehart:

• Signup to get his blog posts by email:
• Follow his blog RSS feed
• View the rest of his blog posts
• View his blog posts on the Adobe CF portal

Need more help with problems?

• If you may prefer direct help, rather than digging around here/elsewhere or via comments, he can help via his online consulting services
• See that page for more on how he can help a) over the web, safely and securely, b) usually very quickly, c) teaching you along the way, and d) with satisfaction guaranteed