Participating Frequently

Question

ColdFusion 2016 - Connection Failure when executing scheduled task

Forum|Forum|7 years ago
September 18, 2018
5 replies
2306 views

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.

Connector

This topic has been closed for replies.

J

JCC-RRamachandAuthor

Participating Frequently

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

J

JCC-RRamachandAuthor

Participating Frequently

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

Community Expert

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.

/Charlie (troubleshooter, carehart. org)

WolfShade

Legend

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,

^ _ ^

D

Dave Watts

Community Expert

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

Dave Watts, Eidolon LLC