ColdFusion 2016 Scheduled Tasks

[StephenHowerd1]

I have scheduled tasks in CF 2016 . They have been running successfully for years however, now it runs but actually it does not. The scheduler log says it is triggering but actually does not. When the task's URL accessed directly from browser the CF page actually get executed. When I set the  "set to save output to file" the log  says "Connection Failure"

I have restarted the CF instance with no successm Any advise would be of great help on what could be the issue with scheduled task.

[collaboranaut]

Same error

https://community.adobe.com/t5/coldfusion/tasks-amp-ssl/td-p/11212038?page=1

[Charlie Arehart]

collaboranaut, I'm not so sure we should presume that Stephen's error here is the same as that one, which seems a very specific and unusual problem. Stephen's here is a very general and common one, and there are various solutions.

Most often, it's caused by a change on the server which your scheduled task URL is pointing. And most often, to get it working, it's just a need to update the JVM that CF uses. (Less often, it's a need to import a certificate--though that's what most would recommend.)

So Stephen, check out a blog post I did on the first suggestion (updating the JVM that CF uses): 

https://coldfusion.adobe.com/2019/06/error-calling-cf-via-https-solved-updating-jvm/

And let us know if that helps.

[rahmed09]

Hello!

we've started seeing similar issue on CF2016 where the Scheduled tasks works without any issue when pointed to a bit older JDK (i.e. jdk1.8.0_321), but with anything above this, I get the following error in the logs..

"Information","DefaultQuartzScheduler_Worker-1","10/24/22","11:17:56","","Task DEFAULT.NGA Notifications triggered."
"Error","DefaultQuartzScheduler_Worker-1","10/24/22","11:17:56","","Connection Failure: Status code unavailable "

I've tested with these JDKs (jdk1.8.0_331, jdk1.8.0_341, jdk1.8.0_351) and i'm totally stumped at this point...

[rahmed09]

correction: The jdk1.8.0_331 works, but when the JVM pointed to either jdk1.8.0_341 or jdk1.8.0_351 the Schedule tasks doesn't work

[Charlie Arehart]

Rahmed, is the 331 something you've had in place for months, or did you just install it? If not "just installed", my bet is that you or someone had tweaked it to "work" in months past--and the newly installed ones don't have that tweak.

What I'm referring to is that since 1.8.0_291 (in Apr 2021), Oracle changed things so that CF (or any app on Java) can't call out to servers (via https) unless those servers support tls 1.2 or above.

Since you're running cf2016, and so people there are lax about security, the URLs in question may be on your own server, and you may there be on an old version of Windows, still not yet supporting tls 1.2 or above by default. 

There's a tweak one can make to the jvm, in its security.properties file, to remove tlsv1.1 and tlsv1 as "restricted" algorithms. (It applies to Java 8 AND 11.)

And you may have done that on your Java 331 but not remembered to do that on the new ones from 341 and up. That's my guess, based on what you shared at least. 

Ring a bell? I have more on the matter in my blog post on the 351 update last week, where I point to my post from Apr 2021, with all the details on this tls matter, what to change, why, and where. See carehart.org/blog.

Or let us know if you solve it some other way, or confirm this does not help. (You will need to restart cf once you apply the change) 

[rahmed09]

Thanks I appreciate your help!

the issue got resolved by adding the following line in JVM arguments using the CFIDE.

-Dhttps.protocols=TLSv1.2

Its might not be a secure solution. but for that I believe we'll have to import the cert which our application uses into the JDK itself...

[Charlie Arehart]

I realize you'll be happy with that workaround, and glad you found it. As for whether it was the only solution--or even needed if other issues were sorted, I'll at least hope that anyone else who finds this will more carefully consider what I offered.

You may have merely treated a symptom, rather than the root cause of your problem. 

[Dave Watts]

Hi, @Charlie Arehart ! I actually think this is a perfectly acceptable solution. Moving to newer JVMs is usually an improvement as you know. This particular JVM is not the very latest, but it allows you to support TLS 1.2 with an easy JVM argument. It's not as good generally as even newer JVMs, but it'll work fine with that argument.

Of course, the OP should migrate to a supported version of ColdFusion too, but that might be beyond his or her control. So, I guess we take what we can get!

Dave Watts, Eidolon LLC

[Charlie Arehart]

I hear what you're saying, Dave. But I stand by what I asked about yesterday that the OP never responded to. Such JVM args are not always the right solution to a problem--and maybe not the right solution for ALL apps on that server. And even if someone has only "one app", it may still not be the right solution for "calls out" from that CF instance/app to the various things it may call out to, whether as cfhttp calls, or admin config of db servers or mail servers, and so on.

Of course, the same can be said about updating a jvm. But I want to be clear: I wasn't saying that the OP's only solution WAS to update the jvm. I was trying to help them understand why their 331 worked but not those above it--especially if it may have been that they did something with the 331 that they simply forgot to do for the later ones. Again, see my comment from yesterday for more. 

More to your point, Dave, are you concurring that something about 1.8.0_241 or above NEEDED that jvm arg in a way that 331 and below did not? I'm not aware of that, but I'm always open to learning--as indeed I have from you for now 25 years! 🙂

[Dave Watts]

Haha, you haven't needed to learn anything from me in a while! My recollection, though, is that there were basically three levels of JVM support for TLS 1.2, as implemented from oldest to newest JVM versions:

- no support at all

- no default support, but it could be enabled with a switch

- support by default, no switch required (and maybe older TLS versions no longer supported?)

So I jumped into this with the assumption that the OP was using the oldest JVM, which didn't support TLS 1.2. Upgrading to a newer JVM - but not the newest - would let you use TLS 1.2 if you specified the appropriate switch. Upgrading to the newest JVM would automatically use TLS 1.2. Since lots of web sites have switched to TLS 1.2, it's a good guess that you need to use TLS 1.2 with your CFHTTP client.

Now, I may have COMPLETELY MISUNDERSTOOD what was being discussed, and if so I apologize. It wouldn't be the first time!

Dave Watts, Eidolon LLC

[Dave Watts]

If those are supported, they're as secure a solution as you're going to get! Increasing the TLS requirement to 1.2 is good, and importing certificates is something that server administrators do all the time (and also is good).

Dave Watts, Eidolon LLC