CFCONFIG save cache not working until after server restart.

I am running a cluster of docker containers based on ortussolutions/commandbox:lucee5-alpine.

As part of my build I add the datasources and a cache using cfconfig.

box cfconfig datasource save name=$MY_DSN dbdriver=mysql host=$MY_DSN_HOST port=$MY_DSN_PORT database=$MY_DSN_DATABASE username=$MY_DSN_USERNAME password=$MY_DSN_PASSWORD
box cfconfig datasource save name=sessionstore dbdriver=mysql host=$MY_DSN_HOST port=$MY_DSN_PORT database=sessionstore username=$MY_DSN_USERNAME password=$MY_DSN_PASSWORD clob=true storage=true validate=true
box cfconfig datasource save name=adilasmysqltemp dbdriver=mysql host=$MY_DSN_HOST port=$MY_DSN_PORT database=adilastemp username=$MY_DSN_USERNAME password=$MY_DSN_PASSWORD
box cfconfig cache save name=rediscache storage=true readOnly=false custom:minIdle=8 custom:maxTotal=8 custom:maxIdle=8 custom:host=$MY_REDIS_HOST custom:password=$MY_REDIS_PASSWORD custom:port=6379 custom:timeout=2000 custom:timeToLiveSeconds=0


The datasources work perfectly when lucee loads, but I get this error.

there is no cache or datasource with name [rediscache] defined.

If I restart lucee from the admin panel the cache shows up and works great.

Why is lucee not finding the cache on initial load when it is finding the datasources created at the same time?
Do I have to build in a restart after load, seems real hacky?

If I build the cache from the lucee admin UI, using the same values and then compare the XML from cfconfig to the lucee admin ui they are identical.

Tought I would add to this that the cfconfig commands exists in their own in the build directory.
I execute them by changing the default CMD like this to make it run before the

CMD ["sh", "-c", "$BUILD_DIR/ && $BUILD_DIR/"]Enter code here...

I fixed this by warming up the server, I am assuming that the redis plugin may not have been installed and functioning on inital server start, but after loading and then me restarting it had time to make it all work.

RUN ${BUILD_DIR}/util/

I think this is a timing issue. Lucee tends to ignore caches defined in the config file that reference a non-existent cache provider class. I think Lucee read (and ignored) your cache config on server start and THEN installed the extension, which depending on how you configured it, may have been up to a minute after the server came online. You may want to consider adding a ticket for Lucee so that when it installs a Cache extension, it reloads any config to pick up cache definitions that are not usable. That seems like it would be a great enhancement to Lucee.

Also, you may be well aware of this, but CFConfig also allows you to store your config in a JSON file which you can load on server start. It wouldn’t have affected this particular behavior, but some people like the JSON file better than a series of commands. They both achieve the same end though!

Brad after additional testing, you are correct.
The server was starting and loading the config before the extensions were fully loaded, ignoring the extensions on load.

What I did was create a new version of the that after starting the server waits for the extension jar files to exist in the Lucee bundle.


Run our normal build script, which will warm up our server and add it to the image


Make sure that all of the extensions have loaded.

echo “Check for REDIS”
while [ ! -f /root/serverHome/WEB-INF/lucee-server/bundles/redis.extension- ]
sleep 2

It takes a little bit longer to build my docker container, but it always (at least so far) seems to have resolved the issue.
I actually prefer this option more than having Lucee reload the config after extension install, which clearly it should do anyway.
This way I avoid a Lucee reload after instantiation and have a steady state on first boot.

I might tweak this later to be more robust, maybe accept a timeout on wait and a list of files to check for…

Thank you

Could you please go vote and comment on this ticket.

What’s frustrating is we asked for a way to force Lucee to install everything up front for this very purpose over 2 years ago but this ticket has never gotten any traction.

I also entered this ticket as well

I voted and commented on both.