Bug 1120628 - [GSS](6.4.z) EAP 6 deploy parseResourceRoot ignore the condition one file be mounted twice [NEEDINFO]
Summary: [GSS](6.4.z) EAP 6 deploy parseResourceRoot ignore the condition one file be ...
Alias: None
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: Server
Version: 6.3.0
Hardware: All
OS: All
Target Milestone: ---
: ---
Assignee: Enrique Gonzalez Martinez
QA Contact: Jiri Truhlar
Depends On:
TreeView+ depends on / blocked
Reported: 2014-07-17 09:56 UTC by kylin
Modified: 2018-12-06 17:22 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2016-09-01 11:11:06 UTC
Type: Bug
bmaxwell: needinfo? (ksoong)

Attachments (Terms of Use)
Reproduce project (12.67 KB, application/zip)
2014-07-17 09:57 UTC, kylin
no flags Details

System ID Priority Status Summary Last Updated
JBoss Issue Tracker WFCORE-700 Major Closed jboss deployment structure error when two deployments share the same dependency 2018-11-01 13:56:00 UTC

Description kylin 2014-07-17 09:56:52 UTC
If 2 deployments have defined the same resource-root, while the 2 deployments be deployed at the same time, the resource-root be mounted twice by VFS, the following Error throw:
java.io.IOException: VFS000017: Filesystem already mounted at mount point ""xxxx""

Reproduce Steps:

1. Start JBoss EAP (I tested both 6.2 and 6.3 Beta version)

2. Download attachment parse-resource-root-reproduce.zip, unzip
     put mylib.jar to EAP_HOME/standalone
     put ShareLibTest.ear to EAP_HOME/standalone/deployments
     put ShareLibTest2.ear to EAP_HOME/standalone/deployments

3. Deploy both ears via create .dodeploy file correspondingly 

4. Restart JBoss EAP, the following Error throw:

Caused by: java.io.IOException: VFS000017: Filesystem already mounted at mount point "".../jboss-eap-6.3/standalone/mylib.jar""

My Thought

I have debug the EAP 6.2 source code, the defect code should be around org.jboss.as.server.deployment.module.descriptor.JBossDeploymentStructureParser12 line 758

final VirtualFile child = deploymentRootFile.getChild(path);
final Closeable closable = child.isFile() ? VFS.mountZip(child, child, TempFileProviderService.provider()) : null;

1. child.isFile() used to check whether a file be mounted, for example, both ear point to resource-root mylib.jar, if 1st deployed, the mylib.jar will be add the VFS mounts map, then deploy the 2nd, the child.isFile() will return false, mylib.jar not be mount twice.

2. While 2 ear be deployed at the same time, 2 MSC threads both run child.isFile(), because mylib.jar didn't be added to VFS mounts map, so child.isFile() in both MSC threads return true, the mylib.jar be mount twice

Comment 1 kylin 2014-07-17 09:57:22 UTC
Created attachment 918656 [details]
Reproduce project

Comment 2 kylin 2014-07-18 01:13:27 UTC
1. add java OPT 
-Dorg.jboss.server.bootstrap.maxThreads=1 let MSC only contain 1 thread, this will avoid concurrent deploy issue, for example:

  1) edit standalone.conf, add system properties in JAVA_OPTS

      JAVA_OPTS="-Xms1303m -Xmx1303m  -Dorg.jboss.server.bootstrap.maxThreads=1

  2) Start JBoss EAP with standalone mode

  3) There will only one MSC thread for service installing, no possibility of current deployment 

2. Install external jars as a module, define module dependencies in jboss-deployment-structure.xml file.

      <module name="mylib module name" />

Comment 3 Enrique Gonzalez Martinez 2015-05-19 12:01:10 UTC
This is reproducible in 6.4.x branch.

The problem as kyle said is VirtualFile::isFile

a) When it is executed in sequence

  1) The first time is called with the argument "path", VFS is using RootFileSystem and it is considered a file.  
  2) Once it is called the second time, VFS is using JavaZipFileSystem (is mounted during the first call) and this time is not considered a file.

b) When is executed in parallel 
  # both of them are using RootFileSystem. The second time VirtualFile.isFile is called throws an exception (Caused by: java.io.IOException: VFS000017: Filesystem already mounted at mount point)

Comment 4 Enrique Gonzalez Martinez 2015-05-20 10:59:44 UTC
Testing a bit more I found more consequences for this problem making a deployment unusable

The description of the problem:

a) Create a lib. This lib will access resources inside itself (i.e: reading a text file, properties, etc...)

b) create two applications with a jboss-deployment-structure.xml in the META-INF with a) as a dependency.

c) deploy both apps (exploded). (in sequence)

d) test the apps (both of them work). They can access those resources inside a)

e) undeploy the first application -> the shared lib is unmount

d) the second application is unusable as the lib is unmount and cannot read any of the files inside the lib.

Comment 5 JBoss JIRA Server 2015-08-17 07:17:06 UTC
Enrique González Martínez <elguardian@gmail.com> updated the status of jira WFCORE-700 to Closed

Comment 8 Enrique Gonzalez Martinez 2016-09-01 11:11:06 UTC
This was a misuse of the  file and upstream was rejected. closing it.

Note You need to log in before you can comment on or make changes to this bug.