RDS not working in Coldfusion 2021 update 16

[elisabethf82215657]

On my local development configuration with IIS 10 and Coldfusion 2021 Update 16, the access of the IDE to RDS does not work any more via IIS.

In the isapi_redirect.log file I see the following lines:

[Thu Oct 10 10:46:00.677 2024] [11236:21128] [warn] jk_check_path::jk_util.c (2476): Blocking this uri: [/CFIDE/main/ide.cfm] since its starting with cfide

If I change the port to the port used by Coldfusion Administrator in the IDE, RDS works, but I am still not able to use the debugger. The message received is the following:

(I know that Coldfusion builder is EOL and I actually use Visual Studio Code for development, but I was still not able to get the debugger to work there, so I use Coldfusion builder for debugging at the moment)

Any idea, how to configure this?

[Priyank Shrivastava.]

Hi @elisabethf82215657 

/CFIDE is blocked from IIS/Apache from update 8 due to security reasons. So you need to connect the IDE with ColdFusion internal port for debugging. 

[Charlie Arehart]

And beyond what Priyank said, you say (Elisabeth) that you "change[d] the port to the port used by Coldfusion Administrator in the IDE, RDS works, but I am still not able to use the debugger."

Are you saying you changed a port within the cf admin (you said "in the ide", which some use to refer to the cf admin)? If so, what did you change?

Or do you mean you changed cf builder's rds connection settings to use the port of the cf admin (which is what Priyank was suggesting)?

And it seems you mean that, but then you get the error about the debugger specifically. In that case, are you confirming that you were able to use THAT CF builder with THAT Cf instance BEFORE that Cf update? It would seem odd that the update would affect the debugger.

But to be clear, there are settings in the cf admin and jvm args to affect the debugger. But if things were working before and the only change was the update, I'd be surprised for that to affect the use of the debugger feature in cf builder.

BTW, if the debugger worked with that instance with the CFBuilder debugger, it should have worked with the vscode CFBuilder extension--at least as long as it was configured for rds and debugging the same way as the old CFBuilder was for you. The fact that it didn't is curious, but I'd think that was more about the configuration in "the ide"...meaning in the editor, also known as an ide. 🙂 

[elisabethf82215657]

Hi everybody - sorry I was not clear.
I did not change any ports in the coldfusion admin. The debugger is configured with the default of 5005 which always worked without problems for me (so no firewall is mixed up in my problems).

What I DID change was the configuration of the local server in Coldfusion builder, which used RDS via localhost and port 80 in the past (which now does not work any more as described above) and now uses the port (in my case 8600) where I can also address the Coldfusion administrator via browser.

And yes, I was able to use THAT Coldfusion builder with THAT Coldfusion instance in the past (except that during the update the IIS connector had to be recreated).

And no, up to now I was not able to debug in VSCode (there is a ticket in the bug tracker which describes my problems from months back and was seconded by me then: https://tracker.adobe.com/#/view/CF-4220242). 

[Charlie Arehart]

First thing: check if cf is indeed is listening on that 5005 port. If not (for any of many possible reasons), then the attempt by cfb to reach it will of course fail.

I elaborate more below, including how to do that as well as more on this general challenge with the debugger, and my hope to try to replicate things. I appreciate how much you and others have suffered, even though others may say "it works for me". Problems like this can be challenging, both to replicate and to solve. 

1) First as for how to check on the port, since you're on Windows, I'd recommend you use the built-in windows Resource Monitor tool. See its "network" tab, then the "listening ports" there, which lists what processes are listening on what ports, and by default it lists them in ascending numerical order by port. Is 5005 there? And is it coldfusion.exe that's listening on it? (And is there only one coldfusion.exe running? You can sort that list by process name and look at the process id's shown, or you look in Task Manager and its Details tab to confirm.) 

Folks on Linux or Mac, or on windows who prefer the command line, can of course use netstat or other such tools to list what's listening on what ports. 

2) If indeed it IS your expected CF process which IS listening on that port, then we'd need proceed to subsequent diagnosis. And there can be various other things to consider. FWIW, I've been helping people overcome issues with CF step debugging since the feature first came out more than 15 years ago. There are several moving parts, and it can be challenging for most folks to get it all working. Once it does, then they use it happily for a long time like you had. 🙂 

And to be clear, I have used the step debugger with cf2021 and the new CFBuilder. So it HAS worked. 

3) But I appreciate that you or other readers facing this problem might ask, "rather than go back and forth with questions and diagnosis here, could you at least just PROVE for yourself and us whether YOU can get cf2021 update 16 to be debugged successfully, whether from the old OR new cf builder"?

And I do hope to try that. But I'm writing from a phone now so I cannot, and I may be blocked helping clients today. So I've set a reminder to try it tomorrow. (And life could get in the way of that.)

3a) Indeed, I'll say that anyone CAN ensure they get my undivided attention on an issue, with priority, by finding and requesting a consulting block of time via my online calendar, offered via my consulting page at carehart.org. As I explain there, if the time is not valuable, you won't pay for it.

And while the calendar doesn't offer time in the weekend, it can be arranged by email. But again I have set my own reminder to try to give this time tomorrow, if not sooner.

4) It does sadden me to see people suffering with this, and I do want to help. It should work, of course. If there's some bug that would be useful to confirm. If it works, then it's a config/diagnosis puzzle to resolve when it does not.

And just as I wrote extensively about troubleshooting this step-debugging in CFBuilder when it first came out, I'd be open to doing it again for the new one. (Though again the problems may not be IN the editor or its setup, as was true back then also.)

5) Finally, it may help some readers to hear that we (I and others) in the community here do try to help immediately when we are able, including attempting to replicate problems. It's just that some, like this, are harder to replicate--especially when we are on mobile--and so may take more time.

But perhaps BKBK or someone else may jump in today or earlier tomorrow than me, to report their experience.