@nak33 , did you ever solve this problem? We never heard back from you after the last comments. ... View more

Harshp, I think I see your solution--and thanks for including your coldfusion-out.log, which offers a clue.   First, the java version may have related to your original problem of your not being able to download updates in the Admin. But it is NOT related to the problem you're now facing, regarding packages.   As for that, and regarding the error you observed, "Error [main] - Unable to install felixclassloader package: org.apache.http.client.ClientProtocolException: URI does not specify a valid host name:file:///D:/coldFusion2021/bundles/felixclassloader-2021.0.02.328618.jar", that relates to something you had told us above , where you had changed your neo_updates.xml to include these two lines: <packagesurl>D:\ColdFusion2021\bundles\bundlesdependency.json</packagesurl> <defaultpackagesurl>file:///D:/coldFusion2021/bundles/bundlesdependency.json</defaultpackagesurl> Notice how the first part of that second line matches your error precisely: "file:///D:/coldFusion2021/bundles". And one might propose you change that the value in your neo_updates.xml file...   But as I review the rest of your coldfusion-out log, I see that specific error occurred only until your Dec 18, 2024  at 05:24:36 AM. After that, your next CF restart a few hours later shows a DIFFERENT variation of that error: Dec 18, 2024 09:12:15 AM Error [main] - Unable to install felixclassloader package: java.lang.IllegalArgumentException: Illegal character in opaque part at index 2: D:\ColdFusion2021\bundles/felixclassloader-2021.0.02.328618.jar That suggests you DID change it, during those few hours. So please tell us now: what ARE the current values for those two lines?   I appreciate that you've been pulled into this mess by the original challenge you had about not being able to pull down the latest CF updates in the CF Admin (which I've said more than once is related to Java). But in "solving" that problem you instead did a manual CF update (as discussed in the CF update technotes and other forum threads you pointed to).   It's very easy for all this to get messed up. There are many variables involved.   Now that you have (it seems) applied the update manually, did you do the step of extracting the zip offered in the update technotes? Did you put it in the d:\coldfusion2021\bundles folder? If so, then is that felixclassloader-2021.0.02.328618.jar there? If not, where is it? Where DID you extract that zip?   The "url" values above can either be a path for the bundlesdependency.json file (and the jar files alongside it) or a URL that RETURNS such a bundlesdependency.json file. FWIW, the ORIGINAL value for both of those lines (for CF2021) in that XML file (about packages) is  https://www.adobe.com/go/coldfusion-packages.   Once you change things, you could try doing the package uninstall/installs either in the Admin or via CFPM, without need of a CF restart. There's more I could share, but let's see where this gets you.   Let us know if that helps. ... View more

Harsh, you've directed to bkbk your response to my point 1 above. Consider also my point 2 above, and the questions I'd asked.   We're here to help, but the answers are not in the detail you've offered so far.    Also, if you "just want this solved" without all the back and forth, I'll note that sometimes problems like this can be solved more readily by a screenshare session. I offer those on a consulting basis. We might solve this together in as little as 15 minutes, and you won't pay for time you don't find valuable. More at carehart.org/consulting.   But again I've offered all the above and more without obligation, trying to help here.  ... View more

Just to clarify: doing the cfpm merely does the exact same thing as manually deleting the felix-cache folder. (And it, too, will indicate how it can only be done while cf is down.) It adds no other benefit that I've seen (besides alleviating a need to know just where the folder is).  ... View more

Client, how did things work out?  ... View more

Harship, a few things:   1) First, as for your current errors (after doing the manual update and installing all packages as bkbk has suggested), the next thing may simply be that you need to delete the felix-cache folder within this CF instance. That is something disucssed in the update technotes for the October CF update: cf2021 update 17, in your case.   The technotes clarify that certain issues will happen if you fail to do that step--which is rarely something we need to bother with. While the things you mention are NOT what the technote says might happen, can you at least please try it?   It's simply a matter of stopping CF, deleting that folder (such as ColdFusion2021\cfusion\bin\felix-cache), then start CF. No need to "save off" the folder. CF will simply recreate it.  Then try what failed and let us know how it goes.    2) As for the other issues you have raised (from the start and since), I have a few other thoughts: As for your updates not being able to be downloaded (in your initial post), it may have been that your Java (the Java that CF is/was pointing to) was outdated, such that the https call from within CF to the Adobe servers failed. But you worked around things by downloading the update. Fair enough. Have you yet updated the Java CF uses? What Java version is reported in use, in your CF Admin "settings summary" page? Then you show you changed the neo-updates.xml file (per comments from BKBK you found in a post you pointed to). That link failed. Perhaps you meant this specific comment. That's related more to doing manual updates, especially when CF can't reach the Adobe update server (as discussed in my first bullet).  The packagesurl value you changed relates specifically to the package update process (rather than the "core" update process, updating CF itself). Again, once you update the Java you should be able to do the CF updates within the CF Admin again: and you'll want to correct that xml file to revert back to the original value. Note that the CF Admin even offers a button to restore that default, on that Package Manager page offering the updates, and its "settings" tab at the top of the page. You shared your logs showing that the install of that update (the core update) had worked, with 0 fatal errors. That's good. And you showed the bottom of that log, indicating that several packages would next be updated--and good for you in noticing that. But did you catch that it says it would do those updates when CF was next started? The message ends, "ColdFusion server is currently not running. The package will be installed automatically once server is up." If you wanted to understand what happened back then (before you installed all the packages with cfpm as bkbk proposed), it could help for you to look at the CF logs (specifically coldfusion-out.log), at the time of that update log (we don't see that date/time in what you shared above). During that startup of CF, you will see it indicating the uninstall of several packages (those to be updated, and their dependencies).  But are there any errors AFTER that as CF was coming up that day? This isn't important to answer, if the other points above get you going. If nothing else, I leave this for future readers to consider. ... View more

A heads-up: folks might miss the importance of the phrase above, about how among the removals will be removal of "cfscript support for script- based CFCs, such as query and storedproc".   I had in fact highlighted in my first comment here (the day of the post), stressing how this meant (at least) that code using the query cfc (as in new query or other forms of cfc invocation) would need to be changed, such as to queryexecute. I should have elaborated a bit more regarding OTHER of the old "cfc-based tags for script" being removed, including how to find them and how to change them. I do that here.   As the phrase indicates, this removal extends to many more instances of tags which were originally implemented in script as CFCs (first in CF9, and more in 9.1). I list them below. And I have more to share related to this specific removal, which I hope folks will appreciate. (I realize it's a long comment: I was torn whether to do it as a blog post. Maybe I still will. This started out as a simple comment but grew as I wrote. I wanted to go ahead and get this out today, as it came up in today's Adobe webinar on CF2025.)   1) The point of this removal (of CFC-based tags as script) is that you will need to find ALL such occasions of using them (not just the one query or storedproc mentioned above). And then you will need to change them to the NEW forms of script support (introduced in CF11, for nearly ALL tags), which is documented briefly (showing conversion from the "http cfc" to the new cfhttp statement, as a representative example) here: https://helpx.adobe.com/coldfusion/cfml-reference/script-supported-tags-and-functions.html   2) As for what tags were introduced as CFCs for use in script, in CF9 (which will be removed in CF2025), they were: ftp (for <cfftp>) http (for <cfhttp>) mail (for <cfmail>) pdf (for <cfpdf>) query (for <cfquery>) storedproc (for <cfstoredproc>)   These were/are documented here: https://helpx.adobe.com/coldfusion/cfml-reference/script-functions-implemented-as-cfcs.html   3) Then as for those added in CF 9.1, they were: dbinfo (for <cfdbinfo>) imap (for <cfimap>) pop (for <cfpop>) ldap (for <cfldap>) feed (for <cffeed>)   And these were/are documented here: https://helpx.adobe.com/coldfusion/cfml-reference/script-functions-implemented-as-cfcs/script-functions-implemented-as-cfcs-in-coldfusion-9-update-1.html   4) Beyond those, I also found there are also these: collection (for <cfcollection>) index (for <cfindex>) search (for <cf search>)   Indeed, if anyone might wonder "just where are these CFCs?" that were used for support tags as script, they are deep within the customtags folder of your CF instance, such as \ColdFusion2023\cfusion\CustomTags\com\adobe\coldfusion. And that's where I found these other 3.   5) FWIW the two docs for CF9 and 91 above DO clearly show how Adobe has been "deprecating" the use of these old cfc-based script implementations of tags since CF2018, as was also discussed in the deprecation guide since then as well.   Again, the main point here is that in order to move to CF2025 you will need to change your code where you may still use these old CFC-based forms of script elements to instead use the new form added in CF11, as I noted above is documented here. There's even more discussion of that CF11 change (with examples) here: https://helpx.adobe.com/coldfusion/cfml-reference/coldfusion-tags/tags-r-s/cfscript.html#Scriptsupportfortags   6) Finally, I will note that sadly you can't just hope to "find all these" by doing a code search for each as "new http" or "new query", for example, because in CFML there are of course multiple ways to instantiate a CFC. Some coder in the distant past could just as well have implemented this "change of script to support tags via CFCs" by using the creatobject function or cfobject tag. In fact, examples of these are shown in that 9.1 doc I'd offered above.  Heck, someone could even use cfinvoke (to call a method, even while instantiating a CFC).   7) As I said in my first comment here (the day of this post), some of these removals are going to be QUITE challenging for some folks--and sadly we can't even experience them yet if you DO join the beta, as they are NOT yet reflected in the beta 1. They are due to be reflected in the beta 2, due in early January.   Indeed, I fear it's going to be a bumpy ride, not just in January or whenever CF2025 comes out but especially when in the future people try to move to CF2025--whether from 2023, 2021, 2018, or older. Many I fear will have code that's not been touched for years but always "just worked" despite the deprecation of these (CFC-based tags for script) in CF2018, and some other things (like parameterexists, which was deprecated over 20 years ago). I hope this comment (or a blog post I may create) will be helpful to them in the transition.   (I'm not at all here questioning or raising for debate the removals. I'm aware of the other comments here and elsewhere on how "removing old cruft is a good thing for any language". I'm just trying to help people navigate the potential minefield.) ... View more

I agree with Rafael: any mechanism to automate setting this would be very much appreciated (setting the package update url, by other than the admin or editing the xml file holding it). There are a couple of possible means.    First, an env var would certainly benefit both those familiar with adding such to the jvm.config (via the -D arg), as well as those running the cf docker/container image.   Even more valuable could be the ability to control it via the cfsetup tool (added in cf2021). This could help both those audiences, as well being another means to promote use of the cli cfsetup tool. For those not aware, it lets you change virtually any cf admin setting, removing the need to use the cf admin or edit xml files. It can also export or import settings via json (similar to Commandbox cfconfig, a still more powerful tool that long preceded cfsetup). It also lets you easily import that json into the startup of a container. Either way, it could have really helped here, but I found it had no support for this package url setting.    Adobe folks, do you need us to add an ER for this, or are you perhaps already working on it given this repeated update problem? ... View more

I can confirm...and I can say that it was working in just the last couple of days, as I'd been looking at some posts here.   Hope someone can fix it.   There are some other longstanding issues that deserve some attention as well, but let's not let better stand in the way of good enough.  ... View more

Thanks for the update, glad it's resolved now, and glad what I offered may help you (or perhaps others also) down the road. 🙂   As for that code change affecting step debugging, that's fascinating to contemplate. I can't see how it would matter. As I said I my reply, error handling and the debugging output are unrelated. As for errors and the step/line debugger, there IS provision (in the CFBuilder setup) to indicate if the debugger should STOP on errors...but I'd not expect that to PREVENT the step debugger working.   But then you only said about it that it "does not work", so it was not quite clear in what WAY it wasn't working for you: opening but not stepping? stepping but not showing expected results? and so on. Anyway, for now things work for you and perhaps that's all that needs to be said. Future readers can press for more if interested. 🙂 ... View more

While many readers may yawn at this list, some items will have far more impact than others--either because they're still likely quietly in use with people ignoring/not noticing the past deprecations (parameterexists vs isdefined, gettemplatepath getbasetemplatepath, the query cfc vs queryexecute; as well as cftable, htmleditformat and others), as well as the yui-based tags--that people could and did "unretire" by restoring the yui folder, per the cf deprecation page's instructions (which will be removed).   All these are finally REALLY going away, folks. REMOVED, not just deprecated. Such code will fail. And these aren't things which can be fixed with a global find/replace.    Others with likely significant impact are the removal of support for MS Access, Axis1, COM support, and more. While some will say they've "never" used them or not for "many years", I see people still using all those (in the community or in my support work). This will indeed be a "historic" version upgrade, as bkbk noted.   Further, there are a couple things not mentioned here that were discussed in the beta--and I feel comfortable saying it, for the sake of completeness (as it seems just an oversight here).   First, some good news: Adobe DOES plan to update the cfml code compatibility checker (in the cf admin) to identify all these changes. That will help many in preparation. Similarly, Pete Freitag  has recently added compatibility scanning to his wonderful Fixinator tool (commercial), and I'd expect him to add all these to that feature.   Second (and finally, for those who've read this far), and bad news for some: the note above doesn't currently communicate something important regarding cfmx_compat. Not ONLY will the jvm arg be removed (which allowed reversion to that as the default), but also the ability to USE that cfmx_compat value for encryption/decryption will be removed. That was never clear from the discussions of the June cf updates that first addressed the change of default. But the discussion in the beta forum did confirm Adobe plans to remove this also, which again means work for the many who still use that. (I have a blog post at carehart.org from July as a follow-up to that update, elaborating on the impact of the change regarding cfmx_compat.)   I do hope that the table above will be revised to clarify that COMPLETE removal of cfmx_compat. (Sadly these removals are NOT yet implemented in the first beta, so we are still left to only anticipate what's been said here, versus actually experiencing it.)    And time will tell how truly significant the impact will be. For some, it will be inconsequential. For others... we shall see.  ... View more

Laura, are you referring to wanting the CF "debugging output" (which appears at the bottom of CF pages)? or are you wanting the interactive step debugger (which you would use via the CFBuilder IDE)?   Your mention of the debug port and your first screenshot are about the latter (step debugging), while your 2 of your 3 other screenshots are about the former (debug output).  To be clear, the two sets of features (and their settings) are technically unrelated to each other.   And I'm going to assume for now you are referring to the debug output feature (since you showed those 2 screenshots related to it), and that the issue is that you are visiting a page and expect to see the debug output at the bottom but none appears. But you've not shown us the URL for either your CF admin or the URL you're testing, so for now we have to do some guessing.  Is the CF which you're testing against implemented on your own machine?    And if you drop this code into the CF page, it will show the IP address which CF sees you coming from:   <cfoutput>#cgi.remote_addr#</cfoutput> or as cfscript: writeoutput(cgi.remote_addr)   The value reported is what needs to be put into your "debugging ip address" list shown in the second screenshot.    Does that help?   BTW, note that if it helps but only temporarily (because your IP address is changing), or you notice that it's not even what you would have thought was your ip address, it could be that the site you're testing is being handled by a proxy like cloudflare. In that case, the IP address may well change, often--but such proxies would normally pass in a request header identifying the original ip adddress, and there's a way to setup CF to regard that header for the value shown for the cgi.remote_addr.  I have a blog post on the Adobe CF portal discussing that. And I mention this because that would affect the IP address which would be used by the CF Admin "debugging ip address" list.   If instead you really mean to be dealing with an inability to use the step debugger in CFBuilder, that's a very different discussion with much more to consider.   Finally, since you refer to the error you found in the log, we might wonder if instead of "debugging" you may be referring to wanting to see the "error details" which that "enable robust exception information" option in the 3rd screenshot should enable. If THAT is your problem, that too is a different matter. It also has NOTHING to do with the ip address settings within CF. Instead, that is often blocked for those using IIS as their web server, which is set by default to show error details only to what it regards as "local" requests. See the IIS "error pages" feature and its "edit feature settings" to enable the third of 3 values shown there. But since I'm sitll guessing whether this is at all your issue, I will wait to hear your thoughts. 🙂 ... View more

Um, why would you be installing a CF version that is over 20 years old? If this is for production use, there are stunningly bad security vulnerabilities (fixed year after year on the ten versions that have come out since that one)? And note that being "for internal use only" doesn't protect you from most of those vulnerabilities.    And if it's NOT for production use, did you know you could run the latest version (cf2023) for free with the developer edition (just don't put in any license). The same is true for any cf version whose installer you could find (though only cf2021 and above are currently getting updates).   I appreciate that you were "just trying to help" anyone installing CF MX6.1 on server 2012 (itself 12 years old and no longer updated). I, too, am just trying to help folks in that position: I even have a preso on my site (and youtube) on migrating to cf2023 or 2021 from older ones (though I go back only to 9). More at carehart.org/presentations.  ... View more

Thanks for the update. And to help save future readers time in assessing the question and its replies, could you please use the "correct answer" option on the reply which initially communicated that solution to you?  ... View more

Or still better, the update AFTER what's listed there, which is update 14 for newbye in cf2018.    (Dave, I'm assuming you replied without seeing my earlier reply. You're not wrong in what you say, but someone seeing this shouldn't not stop at what was then the next update when that technote was written and then initially updated.) ... View more

@xfreeman89x , can you let us know how things worked out for you?   You'd reported here on Nov 6 that you were having heap problems, similar to Dave Cordes (who started this thread). We pointed to various aspects of what had been shared with Dave, but it's not clear if those helped, or if you found any new info to share. (In the end, he found his problem was really about new, excessive bot traffic--so it was NOT about CF2023 after all.)   Of course, it's not clear to us if your problem even remains, now a few weeks on.  🙂 Can you confirm? Even if only to report that the problem remains unresolved for you? And if so, are you just restarting CF every couple of days to "solve" the problem?    One other thing: you've indicated in another forum post that you're running on an AWS AMI.  Indeed, one reason I'm asking about the state of things for you is that I know someone else who is running on an AMI, and they ARE on update 11, yet they are experiencing unexpectedly high heap that can't be GCed (so grows to the heap limit and eventually CF must be restarted). As you're on an AMI as well, maybe there's another thing specific to AMI's that could be investigated (or perhaps someone will identify a new known issue).   (Speaking of issues unique to AMI's, and as xfreeman89x already knows, those using them should be aware of another issue: those on an AMI--on AWS OR Azure--will find if they DO apply the latest (Oct 2024) CF update, CF will fails start properly after that. This is fixed with an Adobe hotfix, as discussed by him in another forum post here. You will need to ask Adobe for that hf202300-4224138.jar, at cfsup@adobe.com . This is all one more reason I wonder if there's yet some other memory issue that may be affecting those on AMIs. BTW, this is not to be confused with a DIFFERENT memory issue, reported in another thread by @sdsinc_pmascari and resolved by a code change about calls TO cloud services--rather than merely running CF *on* an AMI.)   Finally, xfreeman89x, if your response to this might be more than just a simple one (especially if your problem remains, or you would ask any questions), I REALLY think it would be best if you would open a new thread here in the forums. This discusison of your problem is buried 4 pages down in the replies to Dave Cordes' original post. Folks may have a hard time seeing it, let alone sorting out the thread references, indentation, etc.  If you DO do that, please offar a link here as a reply, and interested folks can follow along there. HTH. ... View more

Certainly good to hear things are resolved. I'd said in my previous reply's point 5 that you'd find the jkloglevel set to debug, which was causing the problem. Your response was to say "no, it is configured".   I see bkbk then said to change it "in the spirit of" what I'd proposed...but I must say that it's what I was proposing from the very first reply 🙂 (though i admitted I mistook things as your referring to iis--but either way the debug logging was so clearly the issue).    Just a bit frustrating to see this thread drag out, with so much effort on all our parts, for what was identified from the first.   But again, glad it's resolved for you.  ... View more

Glad to hear clicking through helped. As for the title, well they may or may not see that as something to be changed. Often they have legal reasons not to refer to the new versions name before release.   I do realize they've said cf2025 here. That will be helpful if everyone and everything (including the beta files and installed service names) can refer to it as simply "coldfusion 2025 beta 1". (There's been mention elsewhere, publicly, of another planned beta drop due a month later.)  ... View more

Bkbk, did you try just clicking the close button? I did and the error went away and I was left at the correct front page.   FWIW, I didn't mention the problem in my first comment because I'd seen Mark Takata acknowledge a similar problem happening last week, but only for current participants in the alpha. So hopefully this affects few who would see this post. 🙂   Anyway,  I see that Saurav and Priyank both say they will look into also, so sure, perhaps it will be gone soon. In the meantime, can you confirm if you can click past the error?  ... View more

Agh, my bad. I missed that in your first note you were using Apache rather than IIS (you made it clear: it's just that on my phone's small interface, I couldn't see that indication in the title and first paragraph as I was reading the rest of your initial note.)   Then again, you have now shared with us your properties file...and that's one that the CF wsconfig tool would create for in fact an IIS web server connection, rather than an Apache one (even Apache on Windows). Let's take things step by step.   1) What is the name of that file whose properties you're showing? Is it indeed iapi_redirect.properties? If so, that would again be the file that the wsconfig tool would setup for use with IIS. Are you saying that is in the same folder as the mod_jk.log you were initially referring to? that would seem odd.   (To be clear, for the sake of others who may have read my first reply, the name of the log file would indeed be mod_jk.log for an Apache connector rather than isapi_redirect.log for an IIS connector.)   2) The file that the wsconfig tool would create for such properties for an Apache connector would instead be mod_jk_vhost.conf. Do you have that file in this folder? It sure seems you should, if this is the folder that has the large mod_jk.log file.   3) If you do not have both in one folder, that will be odd. Note how the folder you're looking in (within CF's config/wsconfig folder) has a number for its name. Do you have more than one such numbered folder in config/wsconfig? If so, look at the others. Maybe one of them has the mod_jk_vhost.conf...and though it should NOT, maybe that file points to THIS folder where you are finding the large mod_jk.log.   4) Putting all this aside for a moment, as far as the huge log is concerned, if you stop Apache, you will be able to rename the large mod_jk.log. That way, you buy yourself time both to make it easier to work with and to work on keeping it from growing huge again.   5) As for the debug lines, that is indeed controlled by a setting similar to the log_level line I referred to originally. Instead, it's called JkLogLevel, and again its value would be "debug" for the config file that's causing creation of this large log you found. You'd want to change it to "info" (without the quotes)...once you figure out which mod_jk_vhost.conf file is controlling its creation.   6) As for finding what folder that should be, besides poking around in the config/wsconfig folder, it may well be  in your apache conf folder, as in "C:/Apache24/conf/mod_jk.conf".   7)  Perhaps better, you should let Apache itself tell you how it's configured for your sites and their respective config files. In the apache bin folder, you can use the -S -M args on the httpd.exe, to see that. If you have Apache installed in C:\Apache24\bin, this would do that:   C:\Apache24\bin\httpd.exe -t -D DUMP_VHOSTS   Better still, while that will list what httpd conf files are used for what sites you have, you can also ask it to tell you what files those conf files point to, as in:   C:\Apache24\bin\httpd.exe -t -D DUMP_INCLUDES   Let us know how you sort things out. Or if you may want consulting help, I can help (via remote screenshare). More at carehart.org/consulting. But if you ask follow up questions here, I (and others) are happy to help, of course. ... View more

The root cause problem is the presence of the debug lines there, leading to the huge logs. Those lines are NOT enabled by default, so someone there had to enable them. That's easily solved: see the isapi_redirect.properties file in the same folder, and change log_level to info.   ** Upate since posting: as for the rest of what I write here, I missed that Mary was running Apache rather than IIS. While the concepts are the same, the filenames and config elements are different. I correct these in a subsequent reply to here, when she pointed that out in response to this reply. **   Second, the file doesn't have to be allowed to grow unchecked--though that IS indeed the default configuration. Instead, that same file has settings that can control the max size and automatic rotation of that log. For more, see the "log rotation" section of the Tomcat isapi redirect docs, at https://tomcat.apache.org/connectors-doc/reference/iis.html   The same page also discusses the log_level setting I'd mentioned above, and still more that may interest you.   Once you make these changes, restart IIS (not CF). In fact, I'd suggest that while IIS is stopped you should rename the isapi_redirect.log, so that a new one would be created starting at 0 bytes.  You can keep the old one or delete it later.    Let us know how things go.  ... View more

Johnny, in case it's gotten lost in all the threads here, I offered an observation a few hours ago that may be useful for you, based on the jvm args you'd shared.  ... View more

Good catch, Paul, even if it's not Johnny's issue. That said, note also that the redis sessions setting in the cf admin also has a checkbox for whether it's to be used for cflogin processing--making it potentially all the more relevant in this situation.   I realize Johnny may confirm he doesn't use redis for cf sessions at all. (Johnny, this is on the "memory variables" page of the cf admin, new since cf2016, and and set to "memory" by default. Indeed, that cannot be changed if "j2ee sessions" is enabled, on that same page.)  ... View more

I'd suspect the last one on the "issue" machine. That arg was introduced in cf10, to optionally disable the "session fixation" protection that was added in that release, and since. (You can google that phrase to learn more as it's a generic it issue and not specific to cf.) And yes, I could see that affecting the cflogin/cfauthenticate processing, but I as those have to do with processing session tokens.    You should test with that removed from there or added to the other. I realize you'd not want to change a prod instance. Hopefully you can recreate all this in a test setup, using the free cf developer edition or trial.   Or maybe someone else will have a different thought.   One last question: check the cf admin of each instance on the settings> "memory variables" page, specifically the "j2ee sessions" option. Is it the same on both machines?  ... View more

Are you confirming that was the previous cf update level on both boxes? I wasn't asking about the jvm version. When you say the args are same, do you mean you compared them (per the admin or jvm.config)? If you're presuming they should be the same, that could be mistaken of course. Ok Ok I didn't question if the code was the same. I was proposing you carefully assess the FLOW through the code, on each instance (via debugging, not eyeballing). Ok ... View more

Doh! Bkbk's reply came in while I was writing mine (but I didn't see his until after submitting mine). If that gets you going, great. If not, I leave mine here for consideration.  ... View more

While someone else may see something more specific for you based on all that code, I'll ask some potentially clarifying questions:   1) What update where you on before applying update 17? That could be important, especially if you had been on u12 or 13, I as updates 13 and 14 had significant changes potentially affecting backward compatibility. You can assess what update you were on previously using the hf-updates folder and its logs.    And you'd want to check both machines, of course, as that may relate to how they differ for you.    2) You should check also the Java args for each cf instance, as those updates 13 and 14 also offered new jvm args to optionally revert what the updates had changed. It may be that an arg is on one and not the other.   3) You refer to the first request not having a needed var. I'm assuming you mean the first request AFTER login, right?   4) And you refer to the missing var as cfathentication. Besides that being a typo (no "u"), neither dump shows that. I'll assume you meant to refer instead to the one starting with "cfauthorization".   5) You may want to do more to know the flow of control through the different decision points in the code. That may help you to know how that flow differs on the two instances.   6) Pay particular attention to what comes back from the cfquery. That may differ for reasons you'd not anticipate by just eyeballing the code.    But again, maybe someone else will see something more helpful for you from the code alone. ... View more

Wow, sybase 9: that's from 2003-2013. Fwiw, even cf2016 listed only sybase 16 as supported. Of course, that was also only in Enterprise.   Have people figured how to configure such an old sybase with a "newer" cf?  Perhaps. We're not hearing from them here, but Adobe won't help--again you're on cf2016, which has been out of support for 3 years itself.   Will upgrading sybase be necessary? I can't say. It seems wise, since it's out of support for 11 years.   I appreciate that updating the db and cf will be daunting (and may seem "expensive", though "avoiding that cost" is a false economy).   Sorry to not have better news for you. Seems you have some tough choices to consider.  ... View more