[coldbox-4.1.0] javaloader classloader-20100119110136.jar file lock

Is there a way to release the lock on classloader-20100119110136.jar without stopping the Adobe ColdFusion Application Server service? I’ve got CF9 here.

When I deploy new versions of a ColdBox application I typically rename the current application directory as a backup and drop in the new one as a full replacement. In ColdBox 4.1.0 if the application is using the cbantisamy module (which has the cbjavaloader module) it will not allow this file to be moved/renamed/deleted due to a file lock. Only stopping or restarting the ACF server releases this lock. Restarting releases the lock but if someone hits the app before I rename it gets locked again.

In ColdBox 3.8.1 this used to be a problem in the core where this file lived at coldbox/system/core/javaloader/lib/classloader-20100119110136.jar

But now in ColdBox 4.1.0 it’s not in core any longer (which is great) but I still run into the problem because of the cbantisamy module needing the cbjavaloader module.

Any thoughts?

Thanks!
Wes

I would be interested in finding this out as well, as I’ve had to work deployments around it.

Wes, I actually leave that file in place and deploy around it using rsync with *.jar as an exclusion. I just maintain a /current directory, with my releases (last 5) in a /releases directory. The deployment flow goes like this:

  1. Pull new releases in to /releases/[release number]
  2. Rsync /releases/[new release] to /current with delete flag and excluding .jar files
  3. Reinit framework

Rollback just reverses to process using the previous release. Major releases replace the .jar files and restart CF

Are you on Windows?

Yes, on Windows.

Unfortunately. on windows, jars are locked by the OS. So the only way I have found out is to actually stop CF to release the OS locks and wipe and restart.

@Jon thanks for sharing your process, that is really helpful to see. Mine is very similar except way less sexy. After my build process is complete I hand off a single .zip file to the deployment team who manually do the replacement (ouch)…avoiding the .jar file(s) as needed. rsync with the delete exclusion of .jar files would be the way to go – I really like that and will pass that along.

Thanks, @Luis. Now that I know a little more about what’s causing this problem my Google searches are revealing this is not a new problem for those doing Tomcat stuff on windows and other related Java things. Thanks for the additional information. Sigh…Windows…

Wes,

No problem. The Win Server commands I use can be found in the rake tasks here:

https://github.com/jclausen/capistrano-cf/blob/master/lib/capistrano/tasks/windows_server.rake

I’m using Cygwin so that SSH access and common Linux commands are available.

HTH,
Jon

Solution: move to Unix :slight_smile:

Luis Majano
CEO
Ortus Solutions, Corp
www.ortussolutions.com
P/F: 1-888-557-8057