We have been experiencing some issues related to mappings or maybe compilation after the 184.108.40.206 upgrade.
Servlet Container|Apache Tomcat/9.0.16
Java|1.8.0_121 (Oracle Corporation) 64bit
OS|Windows Server 2012 R2 (6.3) 64bit
We have a clusters of 18 VMs running with above configs. When we deploy new code we take half the vms out of the production pool via an F5 load balancer. Stop the tomcat and apache services via windows SC. We push new source to each vm and then use windows SC to start tomcat9 and apache. This has worked well for years. Each VM hosts about 20 virtual hosts.
Since the upgrade we have some issues with some VMS not starting properly. ie. the application.cfc file not initing our cfcs in onapplicationstart (cfcs are called via a lucee mapping). We them have to restart services again. Sometimes that works sometimes it takes several restarts.
This isn’t our biggest issue though. We are currently seeing strange mapping issues. Today everything seemed to have started/loaded fine except that calling /folder in the root of our site was actually calling /index.cfm and not /folder/index.cfm. No errors in the logs. Once this starts to happen stopping the tomcat service is very fast. Normally it takes about a minute or so. Seems that it’s not performing the normal cleanup it usually does. Another issue is that calling custom tags using <cf_tagname fails when the custom tag is in an included file which is called from a subdirectory. The custom tag is in the same directory as the included file. Luckily we only have a few very old custom tags that we removed because of this issue.
The only way to get everything working again is to delete all web-inf folders in each sites root and then restarting windows. At this point it seems the issue is when tomcat9 is restarted. If we restart tomcat9 the issues come back. Hence we need to delete web-inf each time. This is not ideal. Any ideas where could be causing this? My only recourse at this time is to revert to the previous lucee version.
We don’t have any mapping defined at the application level.
Just found this. sounds like our problem. https://luceeserver.atlassian.net/browse/LDEV-2514