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.
/Charlie (troubleshooter, carehart.org)
8
Replies
AdChoices