Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 328630

Summary: Restarting server from STS does not recognise recovered deployments from pickup
Product: [RT] Virgo Reporter: Steve Powell <zteve.powell>
Component: runtimeAssignee: Glyn Normington <glyn.normington>
Status: CLOSED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: eclipse, glyn.normington, jsharier
Version: 2.1.0.RC1-incubation   
Target Milestone: 3.7.0.M01   
Hardware: PC   
OS: Windows All   
Whiteboard:

Description Steve Powell CLA 2010-10-25 12:19:08 EDT
Restart server (i.e. non-clean start) and we see messages like this:

[2010-10-25 17:10:43.238] fs-watcher                   <HD0001I> Hot deployer processing 'INITIAL' event for file 'org.eclipse.virgo.apps.splash-2.1.0.RC1-incubation.war'.
[2010-10-25 17:10:43.238] fs-watcher                   <HD0005I> Hot deploy not performed because file 'org.eclipse.virgo.apps.splash-2.1.0.RC1-incubation.war' is already deployed.

because splash is in pickup but was recovered.

If the same server is then shutdown and started from STS (deploying nothing new) we see the following errors in the console:

[2010-10-25 17:01:23.554] fs-watcher                   <HD0001I> Hot deployer processing 'INITIAL' event for file 'org.eclipse.virgo.apps.splash-2.1.0.RC1-incubation.war'. 
[2010-10-25 17:01:23.695] fs-watcher                   <HD0002E> Hot deploy failed for file 'org.eclipse.virgo.apps.splash-2.1.0.RC1-incubation.war'. org.eclipse.virgo.kernel.deployer.core.DeploymentException: The artifact bundle 'org.eclipse.virgo.apps.splash' version '2.1.0.RC1-incubation' in scope 'null' at URI 'file:/C:/virgo-web-server-2.1.0.RC1-incubation/pickup/org.eclipse.virgo.apps.splash-2.1.0.RC1-incubation.war' cannot be stored in the runtime artifact model as it clashes with the artifact bundle 'org.eclipse.virgo.apps.splash' version '2.1.0.RC1-incubation' in scope 'null' which is already present.
	at org.eclipse.virgo.kernel.deployer.core.internal.PipelinedApplicationDeployer.doInstall(PipelinedApplicationDeployer.java:146)
	at org.eclipse.virgo.kernel.deployer.core.internal.PipelinedApplicationDeployer.install(PipelinedApplicationDeployer.java:123)
	at org.eclipse.virgo.kernel.deployer.core.internal.PipelinedApplicationDeployer.deploy(PipelinedApplicationDeployer.java:190)
	at org.eclipse.virgo.kernel.deployer.hot.HotDeploymentFileSystemListener.deploy(HotDeploymentFileSystemListener.java:174)
	at org.eclipse.virgo.kernel.deployer.hot.HotDeploymentFileSystemListener.deployIfNotDeployed(HotDeploymentFileSystemListener.java:186)
	at org.eclipse.virgo.kernel.deployer.hot.HotDeploymentFileSystemListener.onChange(HotDeploymentFileSystemListener.java:87)
	at org.eclipse.virgo.util.io.FileSystemChecker.notifyListeners(FileSystemChecker.java:245)
	at org.eclipse.virgo.util.io.FileSystemChecker.check(FileSystemChecker.java:166)
	at org.eclipse.virgo.kernel.deployer.hot.WatchTask.run(WatchTask.java:58)
	at java.lang.Thread.run(Thread.java:662)
Caused by: org.eclipse.virgo.kernel.deployer.model.DuplicateFileNameException: The artifact bundle 'org.eclipse.virgo.apps.splash' version '2.1.0.RC1-incubation' in scope 'null' at URI 'file:/C:/virgo-web-server-2.1.0.RC1-incubation/pickup/org.eclipse.virgo.apps.splash-2.1.0.RC1-incubation.war' cannot be stored in the runtime artifact model as it clashes with the artifact bundle 'org.eclipse.virgo.apps.splash' version '2.1.0.RC1-incubation' in scope 'null' which is already present.
	at org.eclipse.virgo.kernel.deployer.model.internal.StandardRuntimeArtifactModel.checkFileName(StandardRuntimeArtifactModel.java:94)
	at org.eclipse.virgo.kernel.deployer.model.internal.StandardRuntimeArtifactModel.add(StandardRuntimeArtifactModel.java:72)
	at org.eclipse.virgo.kernel.deployer.core.internal.PipelinedApplicationDeployer.addTreeToModel(PipelinedApplicationDeployer.java:240)
	at org.eclipse.virgo.kernel.deployer.core.internal.PipelinedApplicationDeployer.doInstall(PipelinedApplicationDeployer.java:144)
	... 9 common frames omitted

I see this on Windows.

Recreate: 
   Installing Virgo Web Server and start it.
   Shutdown the server.
   Install STS, define a Virgo Web Server server, and start it from STS.

Expected behaviour, should see the same 'already deployed' messages.
Comment 1 Chris Frost CLA 2011-05-17 11:20:18 EDT
This error only occurs on Windows, can not recreate on Mac.
Comment 2 Chris Frost CLA 2011-05-18 10:11:06 EDT
Fixed by ensuring that checks by the HotDeployer for an already installed application always us the canonical URI of the file for comparisons.
Comment 3 James Sharier CLA 2012-08-08 12:22:49 EDT
(In reply to comment #2)
> Fixed by ensuring that checks by the HotDeployer for an already installed
> application always us the canonical URI of the file for comparisons.

Hi,

I'm seeing this error when running Virgo 3.5.0.RELEASE in STS-2.9.2.RELEASE. How can I fix the error?

Thanks
Comment 4 Glyn Normington CLA 2012-08-14 05:10:58 EDT
Sounds like the bug may have come back, so best to re-open.
Comment 5 Glyn Normington CLA 2012-12-10 09:51:07 EST
The kernel code in StandardRuntimeArtifactModel canonicalises the URI passed in to  get(URI) and in the precondition check (looking for duplicates) in add(URI, InstallArtifact), but then add goes on to use the non-canonical to add the artefact to its Map<URI, InstallArtifact>.

The proposed fix is to canonicalise the URI input to add and use the canonical form for the rest of the method, thus ensuring that the canonical form is added to the map.
Comment 6 Glyn Normington CLA 2012-12-11 06:16:57 EST
Fixed in kernel commit 2ef25cfe47ff7421d1612086e455b0079da792b8.
Comment 7 Glyn Normington CLA 2012-12-12 04:39:34 EST
The proposed fix in kernel caused a regression in the web layer tests. Reverted the commit to avoid holding up M05.
Comment 8 Glyn Normington CLA 2012-12-12 04:40:47 EST
The symptoms of the problem in the web layer were that this.appDeployer.isDeployed(uri) - returned false with app still deployed and
this.deployer.getDeploymentIdentity(getDefinitiveUri(sourceArtefact)) - returned null with app still deployed.
Comment 9 Glyn Normington CLA 2012-12-12 04:43:42 EST
The failing test case on web was -Dtestcase=org.eclipse.virgo.web.test.WarDirectoryDeploymentTests
Comment 10 Glyn Normington CLA 2012-12-12 10:35:24 EST
The problem was that File.toURI gives a file: URI with a trailing slash when a directory exists, but without the trailing slash if the purported "directory" does not exist. So deleting a directory from pickup closely followed by checking to see if the directory is deployed would generate the wrong URI and fail to find the directory is in fact still deployed.

The fix (and a test to check the fix) are in kernel commit 67e08ddff2e5ca713543e1eccd61bcab5cc06e80 which is currently on the branch 328630-canonical-uris.

I do not intend to rush this fix into 3.6.0 since one attempt already broke a milestone build, there is validation on Windows to do, and I would like this fix to bed in for a while before exposing it.

The current behaviour, although wrong is simply an annoyance as the duplicate deployment exceptions stop the state from being corrupted in any way.
Comment 11 Glyn Normington CLA 2012-12-17 11:26:07 EST
After another Windows specific change and making the URI canonicalisation robust by re-throwing exceptions, I tested that the change fixes this bug and merged the branch into master for 3.7.