http://coldfusion.com logo
Join Slack
Powered by
Hi <@U071QGDLH> / <@U06V253M4> According to HackM...
# box-products
d
Hi @jclausen / @bdw429s According to HackMyCF, the current version of Java which we are using with Commandbox (11.0.14.1) has a security update available Looking at https://adoptium.net/temurin/releases, latest release of Java 11 is jdk-11.0.15+10 Within our build we have updated to use the following command: 
box server java install openjdk11_jre_x64_linux_hotspot_jdk-11.0.15+10 --setDefault
this gives the following:
Copy code
#11 13.96  × | Installing package [java:openjdk11_jre_x64_linux_hotspot_jdk-11.0.15+10:lockVersion]
#11 13.96    | Installing [openjdk11_jre_x64_linux_hotspot_jdk-11.0.15+10]
#11 13.96    | Java version:              openjdk11
#11 13.96    | Java type:                 jre
#11 13.96    | Java arch:                 x64
#11 13.96    | Java os:                   linux
#11 13.96    | Java jvm-implementation:   hotspot
#11 13.96    | Java release:              jdk-11.0.15+10
#11 13.96    | Hitting the AdoptOpenJDK API to find your download.
#11 13.96    | <https://api.adoptopenjdk.net/v3/assets/version/%5B11%2C12%29?page_size>
#11 13.96    | =1000&release_type=ga&vendor=adoptopenjdk&project=jdk&heap_size=normal
#11 13.96    | &jvm_impl=hotspot&os=linux&architecture=x64&image_type=jre
#11 13.96    | This specific Java version doesn't seem to exist.  Valid [openjdk11] r
#11 13.96    | eleases are [jdk-11.0.14.1+1, jdk-11.0.14+9, jdk-11.0.13+8, jdk-11.0.1
#11 13.96    | 2+7, jdk-11.0.11+9, jdk-11.0.10+9, jdk-11.0.9.1+1, jdk-11.0.9+11.1, jd
#11 13.96    | k-11.0.9+11, jdk-11.0.8+10].
#11 13.97 ERROR (5.4.2+00453)
#11 13.97 
#11 13.97 This specific Java version doesn't seem to exist.  Valid [openjdk11] releases are [jdk-11.0.14.1+1, jdk-11.0.14+9, jdk-11.0.13+8, jdk-11.0.12+7, jdk-11.0.11+9, jdk-11.0.10+9, jdk-11.0.9.1+1, jdk-11.0.9+11.1, jdk-11.0.9+11, jdk-11.0.8+10].
Looking at this, CommandBox is attempting to identify available java versions from https://api.adoptopenjdk.net/ If you go to https://api.adoptopenjdk.net/ then you see the following message:
AdoptOpenJDK has moved, the blue download button will take you to the new location.
(blue button links to the adoptium link above) If I understand correctly, it would appear that the functionality for 
box server java install
needs to be updated in order to get any releases subsequent to jdk-11.0.14.1+1 Is that something which is in the pipeline (and if so, when)? If not, is there an alternate approach which can be safely used in the meantime to include and get box to use later java version? we are using docker with our image with the base image using official docker image as follows: 
FROM ortussolutions/commandbox:3.4.5
b
@danlance The bleeding edge of CommandBox has already been moved over to the new Adoptium API a few months back
I just tested and it installs that versions of Java just fine
I've been ready to release CommandBox 5.5.0 for months, just been waiting on Lucee 5.3.9 to finally release 😕
d
Ah ok - yeah we are still running 5.3.7 for most our servers, sue to significant incompatibility issues with 5.3.8 for one of the apps we are running
So… in the meantime, is there an easy sneaky back door to allow us to pull latest java 11 version from adoptium with the current Commandbox 5.42 version we are using?
Or a safe weay for us to download externally and then make sure it is used by CB for all instances?
i.e. earlier in our dockerfile before we run the warmup
b
Honestly, I think you're going about this wrong if you're using this in docker
d
?
This?
b
CommandBox's feature to download JREs is a great way to test or use differnt Java versions for local dev, a CI server, or even maybe a long-lived prod VM with lots of hard drive space
Docker images are genearlly something you want to be as small as possible with nothing extra on disk
So having two JREs in a single image is generally frowned upon as wasteful
It takes up room in your docker registry and makes the image take longer to pull
For my docker images, I usually use the JRE installed in the base image for both the CLI and the server so there is no duplication
So the Ortus commandbox docker images, for instance, use a base image with a JRE already in place and I never touch the auto-download stuff in that context
This does mean Jon has to make new builds so • openjdk puts out a new version • the base JRE images we use get updated • We update our builds • you update yours
It's a little annoying, but since the JRE image is the bottom layer in the image, that's usually the flow
now, you could put a step in your docker build to just update the JRE in the base image. It's a little weird to use a base JRE image and then change it, but it would let you use the version right away if your base images weren't updated yet
is there an easy sneaky back door to allow us to pull latest java 11 version
I don't know that adopt has actually set up a cut-off version per se. So far as I know, versions are still being added to the old API, I think they're just taking longer.
j
@bdw429s @danlance I am on PTO right now, but I can try to retrigger a build and bump the patch version tonight.
👍 2
I can’t just re-trigger, because the JDK version will change
d
@jclausen that would be absolutely very much appreciated if it is possible… typically this java security alert comes out right when we are running final test scripts prior to a relatively time sensitive and complex migration - Sod’s law…
If you are able to let me know either way (signing off for now as in UK) so that we can make neccessary decisions in the morning… that would also be appreciated
j
@danlance I was able to do what I needed to from my phone. When this build completes, the JDK will be updated: https://github.com/Ortus-Solutions/docker-commandbox/actions/runs/2241265381
👍 1
b
In related new-- Lucee 5.3.9 just went gold a few minutes ago
That means CommandBox 5.5.0 will be coming out in the next day or so 🙂
🚀 1
d
Ah cool - I presume we can still use previous versions of Lucee with that?
b
You can always start a server with whatever version of Lucee or Adobe you choose.
The new release of CommandBox was needing Lucee 5.3.9 to power the CLI itself
d
Ah ok - so if we use anything other than default, we will have 2 copies of Lucee I presume?
b
Depends
If you're using a finalized docker build, then the CLI gets removed
If you're not finalizing the builds, you'll always have two Lucee homes, one for the CLI and one for the server, regardless of the version of each
d
We definitely need to look at updating our build process - as our current builds can not be described as small… We are currently relying on processing of environment variables on each instance at run time - so we have CB in our prod builds… which are somewhat massive - they work… but instance startup time can be an issue for autoscaling in high traffic situations… …I just need to get some available client budget for fixing something which already works…
b
Well, some people choose flexibility over size
The smaller you make your build, the more you're "locking" in at build time and the harder it can be to have a single super duper flexible image to use across dev/stage/prod
I have a client right now who wanted to be able to swap out all their config JSON and stuff at deploy time, so we didn't finalize their build which made it bigger and start slower, but it's more flexible
here's some interesting numbers for you (need to go find and copy...)
Here's some numbers I ran for a client who was converting over to the CommandBox-based images with a bunch of possible options for their final images Basic docker file with no warm up • 788 Meg image size (This is only small-ish because it doesn't have any CF engine downloaded/installed) • 45 seconds from start to serving requests • Has external web hits to confirm latest versions of CF Engine, FR, etc and downloads CF Engine on every boot "Warmed up" CF Engine but not finalized • 1.2 Gig image size • 19 seconds from start to serving requests • Has external web hits to confirm latest versions of CF Engine, FR, etc on every boot Finalized single-stage build • 900 Meg image size • 9 seconds from start to serving requests • No external web hits and no downloading Finalized multi-stage build • 466 Meg image size • 9 seconds from start to serving requests • No external web hits and no downloading
d
We already have fixed builds per environment for one of the larger apps, dues to dependencies on an infrastructure level… so moving some of the config back to the build server… is not out of the question… one of our larger images is 2.15GB… and takes 10 minutes before it can handle traffic (including spawning a new host server) Not all of that is docker related… app itself takes a while to load - but at least 6 minutes from when server is up to when app is up
b
holy cow, that's a lot 😉
d
and that is warmed up as well
b
Which may not be a big issue in reality if you have the time and bandwidth
It's not going to work in some sort of super-responsive scaling situation, but that's not most people really
is this adobe CF, or Lucee?
d
Lucee
b
Good 🙂
Would be interesting to profile what's taking so long.
Could be starved for CPU cores (the biggest startup bottleneck usually)
d
Only time it has been an issue is during DOS with enough traffic to overwhelm 4 instances… tatking them down faster than they could be spawned
yeah - we do see very high CPU load for first couple of minutes after server up
Warning for 2-3 minutes of 99% cpu load
2 vCPU AWS t3.large…. so burstable - but we only see that during startup really, typical load is ~15% cpu unless really busy
It’s a really big (as in number of cf files) CMS application…. with ~50 sites Same app with only one simple site, and no legacy hangover code, takes < 1/2 the startup time
It feels like lucee is attempting to compile every file before it starts responding…
as in, time to hitting ready in std-out is much higher with this app… not just the time to complete first request
Hi @jclausen - that build completed… not seeing a 3.4.6 tag on dockerhub however - and all the new builds I’ve looked at still seem to have 
ENV JAVA_VERSION=jdk-11.0.14+9
 Am I missing something?
j
I couldn't add the tag from my phone and it is a different build. I will when I get back in front of a keyboard. You can just use :latest for now.
d
still on old java version
Not on jdk-11.0.15+10
j
Hmm. That means that adoptopenjdk hasn’t even published that version yet
Will investigate later
d
yeah - its only available from https://adoptium.net/temurin/releases
b
@jclausen It would appear update 15 is on the new adoptium API, but not on the deprecated adopt api yet
You may need to update the build to use the new API. It's the same basic endpoints and JSON responses, but a new URL
j
@danlance The new containers just released today will get you back on the JDK upgrade path
d
Thanks @jclausen - much appreciated 🙂
2 Views
Open in Slack
PreviousNext
Powered by