[#RIO-198] OAR file not deleted on WIndows

Rio

OAR file not deleted on WIndows

Created: 24/Aug/09 07:53 PM Updated: 06/Sep/09 02:30 PM

Component/s:

Deployment

Affects Version/s:

None

Fix Version/s:

4.0 M3

Time Tracking:

Not Specified

Environment:

Windows

Description

« Hide

As described in https://rio.dev.java.net/servlets/ReadMsg?list=users&msgNo=615, the OAR cannot be deleted because Windows does not release resources. This in turn causes the Provisioner to continually install the OAR and the services are always deployed, even after the opstring has been undeployed.

A check should be provided to make sure an OAR is not installed if it has already been installed and the OAR file has not been updated

All

Comments

Work Log

Change History

Sort Order:

[ Permalink | « Hide ]

Dennis Reedy added a comment - 24/Aug/09 08:00 PM

A table of processed OARs is maintained containing the name of the OAR and the Date the OAR was last modified. As OARs are obtained from the drop directory, they are checked to see if they have already been installed, and if so, whether the installation needs updating.

The update check is made based on the value returned from File.lastModified. If the value is after the previous installation date the deployment is updated, If not the OAR is ignored

[ Permalink | « Hide ]

Dennis Reedy added a comment - 24/Aug/09 10:34 PM

As it turns out this happens only on Windows (not sure why this would work on *X and fail on Windows, nothing like WORA right?). So I fixed this to move the file and use JarFile instead of JarURLConnection (I need to get the OAR's manifest). The key was JarFile.close(), with JarURLConnection there is no way to close access to the jar.

I also got around not using Rio's DownloadManager (this is a utility that uses an URLConnection to move files around) and instead simply use File.rename() for local file system use. I dont think there should be any issues using this approach for the FileSystemOARDeployHandler.

What happens now is the OAR is moved, then extracted. You should be all set now.

[ Permalink | « Hide ]

Dennis Reedy added a comment - 26/Aug/09 01:44 PM

There still seems to be a latent locking issue with OAR drag and drop using Windows

[ Permalink | « Hide ]

Jeff Ramsdale added a comment - 26/Aug/09 07:29 PM

Steps to reproduce using examples/bean:

1) 'ant oar' - deploys oar successfully
2) 'ant undeploy' - undeploys oar successfully
3) In File Explorer attempt to delete deploy/bean dir. Following error dialog is displayed: Cannot delete bean.oar: It is being used by another person or program.

Interestingly, if Rio is stopped and restarted (I used startall) the oar is again locked and the dir can't be deleted. Stopping Rio releases the lock and allows the bean dir to be deleted.

[ Permalink | « Hide ]

Dennis Reedy added a comment - 03/Sep/09 05:33 PM

I cannot reproduce removing the OAR, the original problem that this issue was reported under. I also get a different result when trying to delete the deploy/bean directory. I dont know why you would want to do this in any event.

If I try to delete the deploy/bean directory, I get an error indicating that bean-dl cannot be deleted. I am not sure whether this should be considered an outstanding issue right now, and if so it will be put under a very low priority.

If the deployment is updated, the (bean) directory will be repopulated with updated contents. I vote that this issue be closed.

[ Permalink | « Hide ]

Dennis Reedy added a comment - 03/Sep/09 08:12 PM

Well, it looks like this issue should be resolved now. I have managed to do exactly what has been described here, including deleting the directory after undeployment, and all works as expected. Please verify this is indeed the case for you and we can close this issue.

[ Permalink | « Hide ]

Jeff Ramsdale added a comment - 06/Sep/09 07:56 AM

Works perfectly--thanks!