Bug 1120628

Summary: [GSS](6.4.z) EAP 6 deploy parseResourceRoot ignore the condition one file be mounted twice
Product: [JBoss] JBoss Enterprise Application Platform 6 Reporter: kylin <ksoong>
Component: ServerAssignee: Enrique Gonzalez Martinez <egonzale>
Status: CLOSED NOTABUG QA Contact: Jiri Truhlar <jtruhlar>
Severity: urgent Docs Contact: eap-docs <eap-docs>
Priority: unspecified    
Version: 6.3.0CC: bmaxwell, cdewolf, egonzale, jason.greene, jtruhlar, ksoong
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: All   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-09-01 11:11:06 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Reproduce project none

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
Workaround
==========
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.

 <dependencies>
      <module name="mylib module name" />
    </dependencies>

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> 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.

Comment 9 Red Hat Bugzilla 2023-09-14 02:11:38 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days