Upgrade jboss-vfs as it is needed by WFLY-1547
jaikiran pai <jpai> made a comment on jira WFLY-1547 A pull request containing a fix has been sent to upstream https://github.com/wildfly/wildfly/pull/5002/. Manual testing shows that it's working. I would like someone from support team to give the latest nightly builds a try once this has been merged, to ensure that this covers their cases.
jaikiran pai <jpai> made a comment on jira WFLY-1547 A pull request containing a fix has been sent to upstream https://github.com/wildfly/wildfly/pull/5002/. Manual testing shows that it's working. I would like someone from support team to give the latest nightly builds (https://community.jboss.org/thread/224262) a try once this has been merged, to ensure that this covers their cases.
jaikiran pai <jpai> made a comment on jira WFLY-1547 This has been merged to upstream. Please try the latest nightly builds https://community.jboss.org/thread/224262 to verify.
jaikiran pai <jpai> made a comment on jira WFLY-1547 Just for future reference - the fix now cleans up the stale tmp/vfs directories when the server is restarted. This is done in a background thread in such a way that the other server startup tasks aren't affected and can immediately continue using the tmp/vfs folder for new contents. The change involves a new API in VFS (3.2.1.Final) and a change in the WildFly code to use that new API. Please refer the pull requests for the exact changes.
jaikiran pai <jpai> made a comment on jira WFLY-1547 [~bmaxwell], can you please get someone from your team to test this out against the latest nightly builds available here https://community.jboss.org/thread/224262?
Shaun Appleton <sappleto> made a comment on jira WFLY-1547 I have tested build #684 wildfly-8.0.0.Beta1-SNAPSHOT from https://ci.jboss.org/hudson/job/WildFly-latest-master/ dated 16Sep2013 It looks good to me. further details: start wildfly in standalone mode with an ear deployed and using -Xrs then examine the vfs directory [sappleto@localhost vfs]$ ls deployment temp [sappleto@localhost vfs]$ tree . ├── deployment │ └── deployment66eab101a317e9dc │ ├── jboss-as-ejb-in-ear-ejb.jar-11d777cd5d07eb11 │ │ ├── contents │ │ └── jboss-as-ejb-in-ear-ejb.jar │ └── jboss-as-ejb-in-ear-web.war-f6a6eb1501fcd144 │ ├── greeter.xhtml │ ├── index.html │ ├── META-INF │ │ ├── MANIFEST.MF │ │ └── maven │ │ └── org.jboss.as.quickstarts │ │ └── jboss-as-ejb-in-ear-web │ │ ├── pom.properties │ │ └── pom.xml │ └── WEB-INF │ ├── beans.xml │ ├── classes │ │ └── org │ │ └── jboss │ │ └── as │ │ └── quickstarts │ │ └── ear │ │ └── controller │ │ └── Greeter.class │ └── faces-config.xml └── temp └── temp8214eb8231b421f └── jboss-as-ejb-in-ear-ear.ear-23e4035bb08c8d13 ├── contents └── jboss-as-ejb-in-ear-ear.ear 21 directories, 10 files kill wildfly and re-start examine vfs dir: [sappleto@localhost vfs]$ tree . ├── deployment │ └── deployment2d33c8864573c359 │ ├── jboss-as-ejb-in-ear-ejb.jar-c4db878fe860c9a0 │ │ ├── contents │ │ └── jboss-as-ejb-in-ear-ejb.jar │ └── jboss-as-ejb-in-ear-web.war-af7a1f0b197d28ca │ ├── greeter.xhtml │ ├── index.html │ ├── META-INF │ │ ├── MANIFEST.MF │ │ └── maven │ │ └── org.jboss.as.quickstarts │ │ └── jboss-as-ejb-in-ear-web │ │ ├── pom.properties │ │ └── pom.xml │ └── WEB-INF │ ├── beans.xml │ ├── classes │ │ └── org │ │ └── jboss │ │ └── as │ │ └── quickstarts │ │ └── ear │ │ └── controller │ │ └── Greeter.class │ └── faces-config.xml └── temp └── temp8ea3b22d2b35a6c2 └── jboss-as-ejb-in-ear-ear.ear-e47cb5a9268c7360 ├── contents └── jboss-as-ejb-in-ear-ear.ear 21 directories, 10 files [sappleto@localhost vfs]$ So no dir or file growth. Repeating start, kill, start, kill, ... ,start, kill shows no growth in number of files or dirs
jaikiran pai <jpai> made a comment on jira WFLY-1547 Shaun, thanks for testing this.
Some documentation will be needed for the release notes, can Jai or Shaun provide it on the BZ?
Dimitris Andreadis <dimitris> made a comment on jira WFLY-1547 BTW, the reaper thread how does it differentiate old tmp content that can be removed from new content that might be created during the startup. Is it checking the date?
jaikiran pai <jpai> made a comment on jira WFLY-1547 >> BTW, the reaper thread how does it differentiate old tmp content that can be removed from new content that might be created during the startup. Is it checking the date? Each temp subdirectory within the tmp/vfs directory belongs to a specific "provider type". The "provider type" relies on a VFS API to create that temp subdirectory content. Now when the server is restarted, the "provider type" code (from within WildFly, for example) will ask the VFS API to create a temp dir for it. The VFS API then checks if there's already a subdirectory for that "provider type" (left behind possibly from a previous run) and if there's one, it renames it to something else and submits a background task to delete the contents of the renamed dir. It then go ahead and creates a new temp dir for this "provider type" which the "provider type" can use to add new content. That way, the deletion of older content and addition of new content can happen parallely without interfering with one another. This code has the details https://github.com/jbossas/jboss-vfs/blob/master/src/main/java/org/jboss/vfs/TempFileProvider.java#L86
In EAP 6.2.0 ER3 jboss-vfs was upgraded to 3.2.2.Final instead of 3.2.0.Final. Is this version correct, please? Upgrade was made correctly and if the version is OK then I can set this issue verified. Both EAP zip and Maven repo zip contain jboss-vfs-3.2.2.Final-redhat-1.jar pom.xml in EAP src zip: <version.org.jboss.jboss-vfs>3.2.2.Final-redhat-1</version.org.jboss.jboss-vfs> <dependency> <groupId>org.jboss</groupId> <artifactId>jboss-vfs</artifactId> <version>${version.org.jboss.jboss-vfs}</version> </dependency> eap6-supported-artifacts-6.2.0.Beta1.pom in Maven repo zip: <dependency> <groupId>org.jboss</groupId> <artifactId>jboss-vfs</artifactId> <version>3.2.2.Final-redhat-1</version> </dependency>
Yes, 3.2.2.Final is correct, 3.2.0 and 3.2.1 had issues in some scenarios.
Thank you. Verified for EAP 6.2.0 ER3.