Lucee 5 with Puppet


#1

I am in the process of migrating a Lucee 4 setup, which is managed by Puppet, to Lucee 5. This is using the JARs distribution. There are a few things that don’t quite make sense so I am hoping that someone can shed some light…

  1. On first boot with no existing files whatsoever, Lucee unpacks itself from lucee.jar and installs the default set of extensions. It seems to update lucee-server.xml to reflect the set of extensions that were installed. So far so good.

  2. In order to deploy additional extensions in a predictable fashion (i.e. with no unpredictable delays due to directory watching), I am trying to make use of the lucee-extensions system property. This seemed to be working well, but in the situation where I had to upgrade an existing extension, I noticed something… It seems that Lucee will start up any existing web application contexts and then react to a version change in the lucee-extensions system property. That means that the newly started runtime environment is still using the previous version of the extension. This requires a) awareness of this issue and b) an additional server restart to fully effect the extension upgrade.

  3. Given an existing lucee-server.xml but no other files, lucee.jar seems to unpack most things as expected. However, when it tries to install the default set of extensions, it seems to forget that they are provided in lucee.jar and instead tries to download them all over the Internet. Is this expected behaviour? I am considering preemptively unzipping the default extensions to lucee-server/context/extensions/available/ as a work-around.


#2

I tracked down the cause of 3)

A couple of unnecessary resource declarations in our customised lucee-server.xml were triggering a chain of OSGI dependency downloads. Removing those has fixed it.

Point 2) is still an issue and in fact worse than I thought. A newly installed extension (no previous existing version) won’t be loaded until the server has been restarted for a second time. It seems that the lucee-extensions system property is only copying the extension files into place and updating lucee-server.xml There is nothing to cause the server to actually load the extension.


#5

Hi @mark.summers,

I’ve added comment for above questions.

  1. In order to deploy additional extensions in a predictable fashion (i.e. with no unpredictable delays due to directory watching), I am trying to make use of the lucee-extensions system property. This seemed to be working well, but in the situation where I had to upgrade an existing extension, I noticed something… It seems that Lucee will start up any existing web application contexts and then react to a version change in the lucee-extensions system property. That means that the newly started runtime environment is still using the previous version of the extension. This requires a) awareness of this issue and b) an additional server restart to fully effect the extension upgrade.

I’m trying to upgrade the version via system property, After restart lucee server once, I’m seeing upgrade version on all my web context. There is no need to restart web context or lucee once again.

Point 2) is still an issue and in fact worse than I thought. A newly installed extension (no previous existing version) won’t be loaded until the server has been restarted for a second time. It seems that the lucee-extensions system property is only copying the extension files into place and updating lucee-server.xml There is nothing to cause the server to actually load the extension.

I’ve checked with new extension (not installed yet) in the system property, It’s load properly once you restart lucee server at once.

NOTE: I’ve checked in lucee 5.2.1.9 installed version

Can you provide following details
In which extension you facing this issue?
In which lucee version you found the issue?


#6

I am using Lucee version 5.2.1.9 exclusively.

To be clear, I am not saying that extension upgrades via the system property are ignored entirely. On the first restart after a system property change, the Lucee configuration .xml is updated to reference the new extension version. However, this doesn’t mean that the runtime environment is using the new version. I’m finding that I have to restart a second time to cause the newly modified .xml to be read and the new extension version to be loaded.


#7

Add the system property for extension and restart server, server loads the extension & It’s working fine at all web context. If we update the extension mannualy, Update version added into lucee-server.xml & updated version working on all web context. If we restart server again, it couldn’t able to load the update extension, server loads older version of extension which is in the system property.

@mark.summers, Can you confirmed that this the issue?


#8

No. That is not quite the issue I am describing.

  1. Configure the lucee-extensions system property to include an extension. Ensure that the .lex file is present in extensions/available. Ensure that the extension is removed from extensions/installed and that the .jar files for the extension are not present in bundles.

  2. Start Lucee and lucee-server.xml is updated to include the new extension. The extension appears in extensions/installed (albeit renamed) and the .jar files are unpacked into bundles. The server appears to start correctly. Emphasis on “appears” here.

At this point, I am able to prove that the extension is not really being started, even when some page requests were received, because certain log messages are absent from catalina.out

  1. Restart Tomcat

Now, the server behaves as expected, with log messages from the extension present in catalina.out

I think that the problem with upgrading extensions is simply a different manifestation of the issue already described: The new version is being installed but not loaded until the second restart.


#9

Hi @mark.summers,

I’ve tried to reproduce the issue from your above mentioned points. Still I’ve no luck to reproduce it. Can you provide some more details,

In which extension issue is reproduced?
Extension working after the second restart?
Have you validated this on Lucee express ?

It’s helps to find out the issue


#10

In which extension issue is reproduced?

I have seen that MS SQL JDBC was not upgraded to the version specified in the system property on the first restart. However, to be absolutely convinced of the issue (via log messages) you would require a custom caching extension and supporting infrastructure (an Apache Ignite cluster).

Extension working after the second restart?

Yes, because the lucee-server.xml modified during the previous startup is now seen.

Have you validated this on Lucee express ?

I have not tried.


#11

I am unable to reproduce the issue with MS SQL JDBC but the caching issue is still present. I would like to focus on that…

  1. In lucee-server.xml define a cache requiring an extension
  2. Make the cache in 1) the default for e.g. object caching
  3. Ensure that the required cache extension is NOT installed (but should be available)
  4. Include the required cache extension and version in the extensions system property
  5. Start Lucee

lucee-server.xml is updated to reflect the installation of the cache extension. However, the custom cache is not started. Instead, Lucee continues to use the default in-memory caching.

  1. Restart Lucee

Now, the custom cache is started and used.

NB: I suspect that this test will only work with cache extensions not included in the Lucee JARs distribution.


#12

The issue is reproducible with Lucee 5.2.2.71 My cache extension is being installed but Lucee continues to use in-memory caching until the next restart.

Also, I think there is something wrong with the order of events during startup. Lucee tries to download all extensions from release.lucee.org, even if they are mentioned in the system property…

Fri Aug 18 10:24:06 BST 2017-578 could not find /bundles/ignite.extension-2.0.0.1.jar in lucee.jar
Fri Aug 18 10:24:06 BST 2017-578 could not find /bundles/ignite.extension-2.0.0.1.jar.pack.gz in lucee.jar
Fri Aug 18 10:24:07 BST 2017-439 download ignite.extension:2.0.0.1 from http://release.lucee.org/rest/update/provider/download/ignite.extension/2.0.0.1/?serverId=76c1a887959aaec1606341f041e5eb2f&serverSecurityKey=a74eaae8-3626-4967-9bc8-e0514c756d4a&allowRedirect=true and copy to /var/lib/lucee/lucee-server/bundles/ignite-extension-2-0-0-1.jar
Fri Aug 18 10:24:09 BST 2017-64 could not find /bundles/ignite.extension-2.0.0.1.jar in lucee.jar
Fri Aug 18 10:24:09 BST 2017-71 could not find /bundles/ignite.extension-2.0.0.1.jar.pack.gz in lucee.jar
Fri Aug 18 10:24:09 BST 2017-695 download ignite.extension:2.0.0.1 from http://release.lucee.org/rest/update/provider/download/ignite.extension/2.0.0.1/?serverId=76c1a887959aaec1606341f041e5eb2f&serverSecurityKey=a74eaae8-3626-4967-9bc8-e0514c756d4a&allowRedirect=true and copy to /var/lib/lucee/lucee-server/bundles/ignite-extension-2-0-0-1.jar
Fri Aug 18 10:24:11 BST 2017-103 could not find /bundles/ignite.extension-2.0.0.1.jar in lucee.jar
Fri Aug 18 10:24:11 BST 2017-103 could not find /bundles/ignite.extension-2.0.0.1.jar.pack.gz in lucee.jar
Fri Aug 18 10:24:11 BST 2017-901 download ignite.extension:2.0.0.1 from http://release.lucee.org/rest/update/provider/download/ignite.extension/2.0.0.1/?serverId=76c1a887959aaec1606341f041e5eb2f&serverSecurityKey=a74eaae8-3626-4967-9bc8-e0514c756d4a&allowRedirect=true and copy to /var/lib/lucee/lucee-server/bundles/ignite-extension-2-0-0-1.jar

2017-08-18 10:24:16.820 extensions to install defined in env variable or system property:99A4EF8D-F2FD-40C8-8FB8C2E67A4EEEB6;version=6.2.0,16FF9B13-C595-4FA7-B87DED467B7E61A0;version=2.0.0.1


#13

This issue seems quite similar…

https://luceeserver.atlassian.net/browse/LDEV-1465

Once again, lucee-server.xml is correctly updated but the runtime environment doesn’t agree.


#14

I’ve not dug into it to the same extent, but I’ve seen some similar issues where even “core” extensions fail to work on a brand new installation/first start without a restart in place. I could reproduce this very well in the ColdBox Travis CI build. When the server very first starts up (via CommandBox) Hibernate is not correctly loaded and there are errors. If you stop and start again, the tests all pass fine. I have a feeling this may be related to some of the issues Mark has experienced.


#15

does the ?alwaysnew=1 trick work?

https://luceeserver.atlassian.net/browse/LDEV-1022
https://github.com/paulklinkenberg/lucee-loganalyzer/issues/1


#16

That doesn’t really apply here. That URL var was specific to the web admin for Lucee and caused admin plugins to reload. In this case, we’re (or at least I’m) talking about an extension being loaded to the point where just regular CFML code can use it from inside your app.


#17

Did this ever get fixed? We had to abandon our upgrade plans because of this and also a major session management bug, which was eventually fixed.