Hi. I'm struggling with CFBuilder extension on Windows + remote server (CF2023, JDK 11.0.17). I had the symptoms above until I setup the environment variables on the remote server (I originally set them up on my machine).   Now I'm seeing another problem - CFBuilder attaches to the server but that's all.  After that its just forever trying to do something but I can't see what - I've checked the logs and the Ouput windows but I see nothing pointing to an issue. Anyone have a clue where I should look for the issue to present itself please? ... View more

To be clear, the jetty folder is about the cf add-on service (not monitoring), which is the solr or pdfg/cfhtmltopdf feature.   There are no documented mitigation steps. One could uninstall the cf add-on service if you're not using it. One could even just yank the log4j jar, if you wanted to just stop the add-on service without installing it.    We can hope that some future update (perhaps coming even this month) will address this more appropriately.    BTW, Ripley, the jetty aspect related to monitoring is yet ANOTHER jetty that Cf has had, starting back in cf9, which was about offering a separate port and web server through which to access the enterprise server monitor. It has its own jetty.xml config file in the cfusion/lib folder, which relies on a jetty jar in that folder. That is NOT the cfusion/jetty folder, added starting in cf11 (if one enabled the add-on service at cf install), which is the focus of the log4j concern in this thread. It can get confusing!    Hope that's helpful.  ... View more

rcasdorph, I hear your pain and am sorry you went through such an experience. I would be very surprised, though, if any crash ("server offline") was really due to an inability to exceed 25 simult requests. There could be many reasons that CF could hang up, and very very few are "solved" by "allowing more than 25 simult requests". Still, I appreciate your frustration, and I guess you tried to change that value to "fix" the problem and found this thread.   So first, the problem remains, even in update 10--and only for those on CF Standard, not those on CF Enterprise nor in the Developer edition. It's solely a Standard issue, due in part to how it mistakenly tries to use the server.xml maxThreads value of the ajp connector, to display in this field (as I explain more in my comments on the bug report), which defaults out of the box to 500.   So what can someone do (besides add votes and comments there, to get Adobe to fix things, both this issue and that mistaken consideration of server.xml entries for this "max simult requests" value)?   You can just change the cfusion\lib\neo-runtime.xml file directly, changing the value for the "requestLimit" element. That really is what CF is USING, separate from what it is SHOWING in that CF Admin field (where it's mistakenly using the maxThreads of the server.xml ajp connect element). Of course, one needs to be careful editing such xml files. It would be wise to take a backup first. But then find this element:   <var name='requestLimit'><number>25.0</number></var> Change that value, save that file, and restart CF. I'm afraid no CF Admin page will confirm the change for you: not the "settings summary" (which will still show the mistaken 500 value), nor the "system information" page (which doesn't show such admin values). But I can assure you that CF honors that value in the neo-runtime.xml, rather than the value from the server.xml which is shown.   I really do hope that Adobe will attend to this problem ASAP. If nothing else, it's causing consternation and confusion, if not also real trouble.   Finally, as for your outage, again there can be many reasons but a common one that hits people is getting an outofmemory error. Did you or can you check your coldfusion-error.log, in the minutes or hour before the outage, to see if it shows any "outofmemory" errors? It could have been a "heap" error, if you have left your newly installed CF2018 at the default heap max of 1024. Most folks need more. Give it a couple more gigs, at a minimum, assuming you have the free memory on your machine.   Or if you find that it's an outofmemory on "metaspace", that is best resolved by simply REMOVING the maxmetaspace jvm argument, as I discuss here.   If you had no oom errors, and no obvious errors in those logs indicating why CF became unavailable, there are still other possibilities, ranging from a need of web server connector tuning (discussed in this post from cf11 which is still valid today, though there are challenges with how the blog post is worded), to perhaps instead you DID hit the "simult req limit" but because of a hangup in something that CF was WAITING for (like db calls, or cfhttp calls, etc.) In that latter case, again, raising the limit isn't really the right answer: fixing what it's waiting for is. There are a range of tools to help spot when this is happening, from the meager "metrics" log, to the new CF2018 PMT, to the classic FusionReactor tool. (And consultants can help find and fix such problems, myself included, if you remain stumped even with such suggestions.)   But I realize that dealing with the outage is perhaps moot for you at this point--and you may well have uninstalled CF2018 in going to 2016 in your panic--though you could have just stopped it and left it there. In either case, I leave these things for you and others in this thread to consider. ... View more

I know this is from a while ago, but I am working with some covid data coming out of a JSON string {"OBJECTID":1,"COVID_Date":1584057600000,"Daily_Case_Count":2,"Cumulative_Case_Count":2,"Daily_Death_Count":0,"Cumulative_Death_Count":0,"UTC_Date":1584079200000}}   and the gross number: 1584079200000 was giving me fits! Your string allowed me to return the right number: dateadd('s', 1584079200000/1000, createdatetime(1970, 1, 1, 0, 0, 0)) output:{ts '2020-03-13 06:00:00'} Thanks for saving my butt!   ... View more

Your intinial post says you are upgrading from CF8 to CF10, but you say your code runs on CF9.  How do you know?  Have you tested it? Did the error message in your second post come from the Code Analyzer for CF9?  Have you run the analyzer for CF10? The LOCAL scope was introduced with CF9, so I would expect the same kind of issues with your application when run under either CF9 or CF10.  I don't think the functionality of the LOCAL scope changed between CF9 and CF10. The good news is that you shouldn't have to change all 2500 instances of "local"; you should only have to make changtes where it is being initially set as a variable or structure.  Look for places where local is being defined as a variable or structure, such as: var local = {}; var local = ""; var local = StructNew(); <cfset local = StructNew()> <cfset local = ""> Try commenting out those lines and see if code will then pass the analyzer without error.  If it does, then go back and remove them. Code that places additional keys/values into LOCAL or variables initially defined using a VAR statement should continue to work (such as the code you cited in your second post). -Carl V. ... View more