First, I suspect you've surmised the situation well, about the error.
And I would recommend that your next step should be to file a bug report at tracker.adobe.com, as I can confirm from my searching there just now that no one else has done so yet. (That's better than hoping someone at Adobe will see this here, plus it gets it considered and tracked for resolution.) Indeed, please share the ticket id/url, and we can add votes to help raise its profile and track any progress from Adobe or thoughts from others. You could also point to the URL for this thread, for added context.
Second, this need not be a showstopper for you or anyone using cf containers. Obviously, you can use all other aspects of cf and the CFAdmin fine. And some would point out how it's frowned upon in the container world to make changes to a running container anyway since they're ephemeral.
But maybe you're making these changes just to get things "setup". Maybe you put in that jvm arg change and THEN got the error. As you may know though, there are several solutions to getting a container setup without need of going into the CF Admin within the container:
- there's provision in the cf containers to auto-import a car file holding admin setting that you've exported from some cf admin
- And since cf2021, you can use the cfsetup CLI tool to manage admin settings, including viewing and changing them, as well as exporting/importing them via json. Again, that could be done against another CF instance or even from within the container. But note that there's an env var to import such settings into a cf container at startup, which is nice
- You can even configure jvm settings on startup of the container, though Adobe doesn't provide for this currently. Instead, it entails some bash fiddling which can be done in a Dockerfile, etc, which I have documented
Indeed, I discuss and/or demonstrate such things about working with CF images/containers which I've done in various presentations or blog posts on my site, carehart.org. Perhaps better still, I show examples of each of the above 3 things (among dozens of other cf container setup variants) which I offer at my github repo, awesome-cf-compose. I realize you're using k8s, but as I note there anyone can use kompose to convert those to kubernetes manifests. I even show a Dockerfile variant for those preferring neither compose nor k8s.
Finally, to your last question about GC settings, I'd argue that there's generally no need to tweak them for most folks. It's often done as a case of the tail wagging the dog, in my opinion: if there's gc problem, the solution is rarely in tweaking GC settings (or even changing cf from its default parallelgc algorithm), at least I've not found it to be the solution in thousands of CF troubleshooting engagements, even involving heap issues.
Instead, the focus in that case should be on finding and fixing what's CAUSING pressure on the heap, which may be about server config (total memory and heap size), unexpected traffic, cf admin config, coding practices, etc. Here again, I have various resources discussing that, or I have helped folks deal with their specific situations--either here in the community or via an online, very short-term consulting engagement.
Long-winded answer to your issue, I realize, but I hope it may help you or others. 🙂
/Charlie (troubleshooter, carehart.org)
4
Replies
AdChoices