Need to know how long your ColdFusionMX instance has been up?
Note: This blog post is from 2006. 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've ever needed to know how long your CFMX instance has been running, did you know there's an incredibly simple solution? It's not really obvious, and in fact it may not work on trial editions of ColdFusion (for reasons explained below), but it's worked on the Enterprise and Developer editions that I and others have tested it.
Some may have noticed that there is a server.coldfusion.expiration variable (one of many read-only variables in the server scope, within the coldfusion structure). According to the docs, it's supposed to represent the date on which a trial edition of CFMX will expire.
But some have found (and I've confirmed) that on non-trial editions it instead reports the time that the server started. Try it youself:
It'll be a date, but is it in the future? or the past? Assuming it's the past, and you're not running on a trial edition, then it's likely the time your server had started. If you could restart your server and test again, you'll know for sure. :-)
Better formatting of the result
Now, if you want to easily determine how long the server has been up, just use the datediff function to report how many minutes there are between the time reported and the current time:
But even better, you could use one of the nifty functions available at the cflib.org that could help present the result minutes in terms of days, hours, and minutes (duration()). Assuming you included the latter in your page, you could then output the value as:
<cfset uptime = duration(server.coldfusion.expiration,now())><br>
<cfoutput>#uptime.days# Day(s) #uptime.hours# Hour(s) #uptime.minutes# Minute(s)
<br>Server started on #dateformat(server.coldfusion.expiration)# at #timeformat(server.coldfusion.expiration)#
I may put together a UDF to submit to the cflib to pull all this together, and which also checks if indeed the server being checked is a trial edition, etc. But I'll look forward to hearing people's feedback first.
Of course, it's worth pointing out that there are of course many tools that will monitor a server's uptime by watching it externally. It may also be possible to ask the operating system to report how long a given process or service has been running. I'll leave that for others to investigate.
Finally, I'll point out that there is indeed a tag in the Adobe Developers Exchange, CF_UpTimeMonger, that purports to help detect server uptime and says it works even for CF 4 and CF5. I have not explored it.
For more content like this from Charlie Arehart:
Need more help with problems?
- 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
- 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
For the benefit of other people thinking of trying this out (of which, I'd imagine there are a fair few):
The duration function isn't m,entioned, so I've coded my own.
Simple enough.. Not sure it needs any explanaton.
Having clicked the link to it, I noticed that it does a common public domain script thing:
It over complicates the matter in order to make itself seem more complex.
Your examples here suffered from no such thing, don't feel that I'm in any way knocking you. In truth, I thank you for being another rare person determined not to overcomplicate things just to make them seem more complex.
I hate the whole "why use the one line that does the job, instead of using 30 lines to accomplish it, and look cooler" thing - something I've just found myself guilty of in typing this.. So I'll stop now then..
The author's email is offered in the source code as well, so perhaps he might appreciate your observation of a more compact solution and would update it.
Or, note that they (Ray and Rob, who run cflib) always welcome new UDFs there, so you may want to send yours along as an alternative. There are a few variants on a single theme. :-)
And as for typing too many lines in a comment (or blog, or article, or email), you won't hear a complaint from me. I'm one of the most notorious felons on that charge! :-) i just trust that some will appreciate the additional info. To the rest, I lament that they may miss out on little gems here and there as they learn. To each their own, of course. Cheers.
As for submitting "my" version (which I can't claim ownership to really, the foundation of the language, utilities and such weren't mine, they were a hybrid between Allaire, and MM's collective, and much valued input) not much point, those who look at the duration function as listed under CFLIB will more than likely realise that it can be shortened, and do something similar, if not shorter/better/cleaner than my function themselves.
Since my function teaches nothing, I don't feel it worthy of being a public resource.
Indeed, to further extent, I'm very much against the whole "library" thing anyway, I can't stand copy & paste coding,whatever justification may be applied to it, it's still not the developer creatng a solution that fits perfectly the requirements, often something is pasted in which has additional functionality never used
- "Scratch" is a wonderful material, anything can be made from it, when combined with "understandng"
Besides which, I'm one of those people that give something like that 10 second bit of coding without wanting my name attributed to it, hence no website listed, and only my first name.
Please do take this with a hint of alcohol.. There are most likely some major diversions from original points, but I felt compelled to respond to such an agreeable chap as yourself.
Guess the feature was a fluke, but it was nice while it lasted.
There are some other ways to get the info, as listed in the entry and comment at https://www.raymondc...
It seems that it IS still working, at least as long as the CF edition is Standard or Enterprise. it does NOT work if it's in the Developer edition mode.
I had reported back in 2013 that it seemed no longer to "work", at least as I and a couple of other folks noted regarding CF9 then. And I pretty much forgot about it.
But had occasion to discuss it with someone recently and it was working for him on CF11! I tested and it was also working for me on CF2016, but then I tested on CF10 and it did NOT work. That seemed odd.
Then I noticed that the CF10 was running in Developer mode (as reported in the CF admin "settings summary" page (and in the cfusion/lib/license.properties file). I put a Standard license key in place (one can put it in the Admin's "system information" page, or in that license.properties file), and I restarted, and now server.expiration DID show the time of the last restart.
Wow, so it's still working, now 16 years later. :-) Odd that it doesn't work in the Developer edition. I suspect the date then holds when the trial edition expired and the developer edition kicked in. (I would be curious what it would hold if one installed CF as the Developer edition from the start. If anyone may try that, let me know.)
It's sad, though, that this is still not documented. The page on the server scope (https://helpx.adobe....) still only mentions its use for tracking the actual expiration of a trial (when in trial mode).
It would also seem helpful for the undocumented behavior to work on Developer edition like it does on Standard or Enterprise.
I'm thinking I may create a new blog post to "reprise" this one. So many people won't look at a blog post that's more than a year or two old, it seems, thinking it "can't still be valid info"!