ColdFusion 2016 - Connection Failure when executing scheduled task

[JCC-RRamachand]

I get a Connection Failure when executing scheduled task on coldfusion localhost. Earlier I used to get the error on the Linux servers and resolved it by importing the app certificates into the java keystore. But this is something new and baffling. Any help is appreciated. Thanks.

[BKBK]

Check the logs. Let us know the details of any errors that have been logged.

[Priyank Shrivastava.]

Hi,

There should be an issue with SSL if the URL is HTTPS. You have to import the certificate.

Thanks,

Priyank

[Dave Watts]

Why is it new and baffling?

What happens if you log into the console and attempt to fetch the same URL used by CFHTTP using wget or curl?

As Priyank mentioned, HTTPS connections to your own server will require certificates to be working properly. You might be able to sidestep that by configuring your web server to accept HTTP connections only from localhost. This is a pretty safe thing to do, but it's easy to forget when you migrate your server elsewhere.

Dave Watts, Fig Leaf Software

[JCC-RRamachand]

Hi all,

Thanks for the quick response with suggestions.

Baffling - I am running the scheduled task on localhost which is http not https, so no question of importing certificates that are required for https sites. So it is still complaining about connection failure. Also I am running on jdk1.8. I am on CF2016 Update 7 using Built in Web Server.

http log:

Starting HTTP request {URL='http://127.0.0.1:8501/jis?reload=true', method='get'}

I copy and pasted the URL on browser and it works. So why not the scheduler working.

scheduled task log:

Task JIS.Wake up - preload CFCs triggered

CF -Out Log:

6405	Sep 18, 2018 12:10:31 PM Information [DefaultQuartzScheduler_Worker-1] - Task JIS.Wake up - preload CFCs triggered.
6406	Sep 18, 2018 12:10:31 PM Information [DefaultQuartzScheduler_Worker-1] - Starting HTTP request {URL='http://127.0.0.1:8501/jis?reload=true', method='get'}

Wake Up log:

Searching file(s): lwas.log

1 - 1 of 1

1	Connection Failure

[Charlie Arehart]

There is an answer JCC. There's always an explanation. 🙂

1) So first, as Dave said, try doing a cfhttp of the URL instead. And then cfdump the cfhttp scope to see if it may offer more than you see in that log. It may well.

Also, after that, try adding a redirect="no" to the cfhttp, in case the problem is that somehow the page you're calling is looping.

2) You may say, "but it doesn't in the regular browser". I get it. It could be that something about the way the code works that changes based on the user agent (in the browser, it would be that of the browser. In CF, it will be something from CF.)

Or it could be something about other http headers being passed in differently between the browser and CF, and your app (the page being called) may be sensitive to that.

Indeed, if the page would "work", you could put in dump of the CFML function gethttprequestdata() to see what WAS being passed in, but I realize that you think the page is not running.

3) That said, do you KNOW that the called page is not running? BTW, it's on 8501. Is that the port for CF itself, so that this is a CF page? We can't tell from the URL.

4) Finally, here's one more sanity check: create a new folder where the old code lives, and put a blank cfm there, along with a blank application.cfm alongside it. Test that page in your browser, and then test it in your scheduled task or CFHTTP. Does that "work"? If so, put some CFML in to show that it's working also.

It could be that your problem is that the CF page you're calling IS running, but is failing for some reason having to do with the code that it's running. If you do this last test, and it works, then you KNOW it must be something the code is doing.

And it could be code not in the CF page you're calling but the application.cfm or cfc that is in the same or parent directories. But putting a blank application.cfm in the test folder, you are ruling that out.

Indeed, if my test "works", try renaming the application.cfm to xapplication.cfm. Now that test code (the blank page in the test folder) will be using whatever application.cfm or cfc is in the folder above it (where your original code lived). If that fails now, then again we KNOW it's about whatever application.cfm or cfc is being called implicitly now.

Let us know if these things get you going.

[WolfShade]

https://forums.adobe.com/people/Charlie+Arehart  wrote

2) You may say, "but it doesn't in the regular browser". I get it. It could be that something about the way the code works that changes based on the user agent (in the browser, it would be that of the browser. In CF, it will be something from CF.)

If I'm not mistaken, and if it hasn't changed since CF11, I believe the user agent for Scheduled Tasks is "CFSCHEDULER".

V/r,

^ _ ^

[Charlie Arehart]

It is, indeed (“cfscheduler”).

/charlie

[BKBK]

Two things baffle me.

1) What kind of resource is jis?

2) What's the deal with: "Task JIS.Wake up - preload CFCs triggered."?

[Charlie Arehart]

BKBK  wrote

Two things baffle me.

1) What kind of resource is jis?

2) What's the deal with: "Task JIS.Wake up - preload CFCs triggered."?

As for 2, that's the sort of line written in the CF scheduler.log (which is duplicated into the coldfusion-out.log), when a scheduled task runs. "task jis" would be the "group" (in the CF admin task definition) and "wake up" would be the actual task name.

As for 1, only JCC can say (it's some URL running on CF's built-in web server). I suspect it's the name of a folder, in which he has an index.cfm, so that no filename needs to be used

[Charlie Arehart]

JCC, you never got back to us on how things went here. After some of the responses, you asked another question which I answered with ways for you to diagnose and resolve the problem:

Re: ColdFusion 2016 - Connection Failure when executing scheduled task

Can you update us?

[JCC-RRamachand]

We had it resolved by changing our security framework in FW/1 that allowed to run the scheduled task with out interfering with the UI authentication.

Thanks All for the Help.

Ram