-
1. Re: JBAS-5953; jar override issue
adrian.brock Sep 30, 2008 10:07 AM (in response to alesj)I don't see the crash problem that Shelley is seeing,
but I do see the test failing.
If I put a sleep between the copy of the file and redeploy,
then the test passes.[ejort@warjort testsuite]$ svn diff Index: src/main/org/jboss/test/jmx/test/UndeployBrokenPackageUnitTestCase.java =================================================================== --- src/main/org/jboss/test/jmx/test/UndeployBrokenPackageUnitTestCase.java (revision 78789) +++ src/main/org/jboss/test/jmx/test/UndeployBrokenPackageUnitTestCase.java (working copy) @@ -152,6 +152,8 @@ Files.copy(goodjar, thejar); getLog().info("Redeploying testPackage: " + testPackage); + +Thread.sleep(10000); redeploy(testPackage); Object home = getInitialContext().lookup("EntityA");
So this is clearly either a caching issue inside the VFS/JDK
or there is some issue with the Files.copy() not flushing properly to the file system
so the server is seeing a corrupt file. -
2. Re: JBAS-5953; jar override issue
alesj Sep 30, 2008 10:31 AM (in response to alesj)"adrian@jboss.org" wrote:
So this is clearly either a caching issue inside the VFS ...
Could be an issue with the way VFS reads
and then closes things - via delay / reaper thread:
- http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4153696#4153696
This was definitely an issue with ProfileService tests,
where we eventually needed VFS::delete impl:
- http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4160591#4160591
But since there are many other similar issues:
- http://www.jboss.com/index.html?module=bb&op=viewtopic&t=142095
Looks like we really need some custom jar/zip impl. -
3. Re: JBAS-5953; jar override issue
shelly.mcgowan Sep 30, 2008 12:37 PM (in response to alesj)Running locally I've seen this test pass, fail with EntityA not found or crash. These different results can be also seen in the full AS 5 testsuite runs depending on which report you view. I was considering a test code change to avoid the Sun JDK issue but didn't want to overlook an issue with the VFS implementation handling the same-name jar redeployment. Previously looking at org.jboss.virtual.plugins.context.zip.ZipEntryContext.java whether checkIfModified() and initEntries() were correct and, alternatively, as Adrian's points out above, possible issue with Files.copy(). Do you recommend to change the test code to avoid the inconsistent result?
-
4. Re: JBAS-5953; jar override issue
adrian.brock Sep 30, 2008 1:40 PM (in response to alesj)"smcgowan@redhat.com" wrote:
Do you recommend to change the test code to avoid the inconsistent result?
Not until we understand the cause of the inconsistency. :-)
This looks more like a server side problem rather than a broken test.
I looked at Files.copy() and it does flush and close the file.
If Ales can't find a problem in the VFS, then I'd suggest trying to reproduce it
with Iced Tea where we can debug the native zip code.
Or failing that, producing a simple cutdown version of the test to give to Sun
so they can fix it. You should definitely give them core dump if you can reproduce
it with the latest JDK6 release. -
5. Re: JBAS-5953; jar override issue
shelly.mcgowan Sep 30, 2008 3:38 PM (in response to alesj)Failure and JVM crash reproducable with OpenJDK 6. I'll file a bug and include testcase and core dump to Sun.
-
6. Re: JBAS-5953; jar override issue
mstruk Oct 1, 2008 4:52 AM (in response to alesj)If the archive isn't deleted before the new version is copied over, I'd try that using VirtualFile.delete().
I was dealing with a similar issue:
- http://www.jboss.com/index.html?module=bb&op=viewtopic&t=138343
- marko -
7. Re: JBAS-5953; jar override issue
alesj Nov 10, 2008 5:59 AM (in response to alesj)"adrian@jboss.org" wrote:
If Ales can't find a problem in the VFS
I've added assertTrue(thejar.delete()) before every Files::copy.
If I run AS with -Djboss.vfs.noReaper=true test passes every time,
w/o that flag it fails on newly added assert before 2nd Files::copy.
I already have VFSUtils::enableNoReaper(VirtualFile),
but looks like it's kicking in too late.
I'm checking if VFSUtils::enableNoReaper(VFS) can do the trick.
(need to add that method first :-) -
8. Re: JBAS-5953; jar override issue
slaboure Nov 10, 2008 8:10 AM (in response to alesj)If we find no good solution with the JDK layer, why not checking at boot time whether a suitable JBoss Native library has been installed and use that instead?
-
9. Re: JBAS-5953; jar override issue
dimitris Nov 12, 2008 1:36 PM (in response to alesj)First, independent of the particular failure we should not let one failing test block the execution of a whole testsuite. So the test should be conditionally skipped for this particular jvm version/vendor combination and another simpler test created to expose the underlying problem either in AS or VFS (but again, not holding the whole testsuite).
Obviously the usecase of re-deploying a jar is quite common and needs to be addressed. What if we jboss.vfs.forceNoReaper=true by default?
Trying to remember what forceNoRepear is supposed to do by lookint at VFSUtils.java I must say I got lost. We have zero documentation on VFS options and their number keeps increasing.
http://anonsvn.jboss.org/repos/jbossas/projects/vfs/trunk/src/main/java/org/jboss/virtual/VFSUtils.java -
10. Re: JBAS-5953; jar override issue
alesj Nov 18, 2008 8:53 AM (in response to alesj)"dimitris@jboss.org" wrote:
Obviously the usecase of re-deploying a jar is quite common and needs to be addressed. What if we jboss.vfs.forceNoReaper=true by default?
I would still leave it at false.
I was able to do a legit workaround the issue,
while global VFS setting is still at NoReaper==false.
I add the following piece to UndeployBrokenPackageUnitTestCase:assertTrue(thejar.delete()); // TODO - this should work Files.copy(goodjar, thejar); getLog().info("Redeploying testPackage: " + testPackage);
so that assert should complain before if things cannot me mounted together.
If I add the following code to old MainDeployer::deployVFS vfs = VFS.getVFS(url); VFSUtils.enableNoReaper(vfs); VirtualFile file = vfs.getRoot(); VFSDeployment deployment = deploymentFactory.createVFSDeployment(file);
the test passes w/o any problems.
In this case it's actually the file openness that prevents it from being overridden.
Reaper is holding it open for 5sec to get better read performance,
but the client == test tries to override it in less than 5sec.
I think users don't really intend to re-deploy things in less than 5sec,
so we should be fine. :-)
If this becomes a more serious issue for users,
we can always add some option to ProfileImpl,
to either use VFSUtils + VFS to enable/disable certain options. -
11. Re: JBAS-5953; jar override issue
dimitris Nov 24, 2008 6:34 AM (in response to alesj)Every we create a VFS optimization are we going to change the MainDeployer interface?
Adding extended deploy method to old MainDeployer: /** * The <code>deploy</code> method deploys a package identified by a URL * * @param url an <code>URL</code> value * @param noReaper enable no reaper * @param forceCopy enable copy * @param caseSensitive enable case sensitive * @throws DeploymentException for any error */ void deploy(URL url, boolean noReaper, boolean forceCopy, boolean caseSensitive) throws DeploymentException; Invoking deploy with noReaper==true allows testjar file deletion.
-
12. Re: JBAS-5953; jar override issue
alesj Nov 24, 2008 6:37 AM (in response to alesj)"dimitris@jboss.org" wrote:
Every we create a VFS optimization are we going to change the MainDeployer interface?
How does Map work with remote JMX call?
e.g.void deploy(URL url, Map<String, String> options);
-
13. Re: JBAS-5953; jar override issue
dimitris Nov 24, 2008 9:23 AM (in response to alesj)Ok, I'll say it differently. The real problem is letting internal details, like VFS options, leak to the client.
The client only cares about deploying a URL. He doesn't care how this should be done or what is VFS and especially not what VFS options would be needed to workaround a particular problem.
If we need to workaround the problem for this particular testcase, that's easy, just introduce a small delay and a note pointing to a JIRA with future work on this.
Extending the MainDeployer api with implentation details doesn't offer any real value, it just complicates things.
And BTW, I think all VFS options should be visible in bootstrap/vfs.xml with the user able to override them in the command line, or by modifying the file. -
14. Re: JBAS-5953; jar override issue
starksm64 Nov 24, 2008 12:30 PM (in response to alesj)It should be the deployment that contains the metadata to setup the vfs behavior as needed, not the deployer call.