This content has been marked as final.
Show 12 replies
-
1. Re: File locking
alesj Apr 22, 2008 6:12 AM (in response to alesj)"adrian@jboss.org" wrote:
"alesj" wrote:
Can someone try how we stand with this on Linux?
There's no locking issue on Linux.
It will however manifest itself as a "leaked"
open file.
I guess it would need something to explictly close()
the URLConnection or JarFile created in the JARHandler constructor
when it is unpacked and replaced?
i.e. My guess is something is keeping a reference previous
packed VirtualFile and hence to the JarFile which means the
connection/file handle is kept open. -
2. Re: File locking
alesj Apr 22, 2008 6:32 AM (in response to alesj)"adrian@jboss.org" wrote:
I guess it would need something to explictly close()
the URLConnection or JarFile created in the JARHandler constructor
when it is unpacked and replaced?
How are you gonna do that? :-)
Since URLConnection doesn't have anything useful to do a close.
See below for more info."adrian@jboss.org" wrote:
i.e. My guess is something is keeping a reference previous
packed VirtualFile and hence to the JarFile which means the
connection/file handle is kept open.
When we do lastModified, for HDScanning purposes, we mostly use URLConnection::getLastModified, which is probably the cause for open handle.
See URLExistsUnitTestCase in JBossVFS.
In the case of non-jar file, I was able to do this hacky thing:InputStream in = conn.getInputStream(); long lastModified; try { lastModified = conn.getLastModified(); System.out.println("lastModified, "+lastModified); assertNotSame("lastModified", 0, lastModified); } finally { in.close(); } assertTrue(tmp.getAbsolutePath()+" deleted", tmp.delete());
Open/close input stream, and was then allowed to delete the file.
W/o this, you cannot delete the file.
But in the case of jar file, see 2nd test in URLExistsUnitTestCase, I cannot do the same hack, since it complains about not specifying the entry:java.io.IOException: no entry name specified at sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:129) at org.jboss.test.virtual.test.URLExistsUnitTestCase.testJarURLs(URLExistsUnitTestCase.java:102)
-
3. Re: File locking
adrian.brock Apr 22, 2008 7:01 AM (in response to alesj)"alesj" wrote:
But in the case of jar file, see 2nd test in URLExistsUnitTestCase, I cannot do the same hack, since it complains about not specifying the entry:java.io.IOException: no entry name specified at sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:129) at org.jboss.test.virtual.test.URLExistsUnitTestCase.testJarURLs(URLExistsUnitTestCase.java:102)
For the top level jar file you should be using the file: url not the jar: url
A top level jar is a file :-)
There used to be a HACK in the VFS JAR code that worked around this issue,
i.e. it reworked the URL based on the parent but I don't see it in the current codebase?
It probably got removed when the url handling was reworked?
Also you need to be careful with JAR files and their URL connections.
The JDK caches them internally and can even mmap them on some operating systems.
So testing a jar entry has changed isn't the same thing as checking the top level file
changed.
Additionally, closing the top jar connection will close the cached version
which can lead to strange errors.
The internal caching is the source of the problems (e.g. locking on windows)
and something Sun have consistently refused to fix. :-( -
4. Re: File locking
adrian.brock Apr 22, 2008 7:06 AM (in response to alesj)"alesj" wrote:
See URLExistsUnitTestCase in JBossVFS.
What is the purpose of this test?
It is testing the JDK rather than the VFS so why is it in the VFS testsuite?
Surely this code:conn = tmpURL.openConnection(); lastModified = conn.getLastModified();
should be changed to use the VFS to check the getLastModified works
and assert the file can still be deleted? -
5. Re: File locking
alesj Apr 22, 2008 8:39 AM (in response to alesj)"adrian@jboss.org" wrote:
"alesj" wrote:
See URLExistsUnitTestCase in JBossVFS.
What is the purpose of this test?
It is testing the JDK rather than the VFS so why is it in the VFS testsuite?
Surely this code:conn = tmpURL.openConnection(); lastModified = conn.getLastModified();
should be changed to use the VFS to check the getLastModified works
and assert the file can still be deleted?
It's Scott's test.
But I think the purpose is to verify that URLConnection::lastModified can also tell you that the file has been deleted.
See comments on the test code:/** * Test file deletion can be detected via URLConnection.getLastModified == 0.
Since like it was already said, we use this for lastModified check on URL based VFS handlers. -
6. Re: File locking
slaboure Apr 22, 2008 8:42 AM (in response to alesj)What about using the same class from the Apache Java implementation? I doubt they have the same bug.
-
7. Re: File locking
alesj Apr 22, 2008 8:48 AM (in response to alesj)"sacha.labourey@jboss.com" wrote:
What about using the same class from the Apache Java implementation? I doubt they have the same bug.
Which class?
And how would you force any JDK to use it? -
8. Re: File locking
alesj Apr 22, 2008 8:51 AM (in response to alesj)You mean this one, that you already proposed. :-)
- http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4134400 -
9. Re: File locking
adrian.brock Apr 22, 2008 9:00 AM (in response to alesj)"sacha.labourey@jboss.com" wrote:
What about using the same class from the Apache Java implementation? I doubt they have the same bug.
Because it uses native code.
But more importantly, even if we use
org.apache.xxx.JarFile or org.jboss.xxx.JarFile
that doesn't mean everybody will.
e.g. Hibernate opens jar files to scan for annotations.
Of course if this causes locking problems then we can use Ales's new unpack option
to give them a temporary copy.
But ideally we want to be minimizing the number of cases where this is required.
i.e. by finding other workarounds that don't require the unpacking. -
10. Re: File locking
starksm64 Apr 22, 2008 12:45 PM (in response to alesj)"alesj" wrote:
It's Scott's test.
But I think the purpose is to verify that URLConnection::lastModified can also tell you that the file has been deleted.
See comments on the test code:/** * Test file deletion can be detected via URLConnection.getLastModified == 0.
Since like it was already said, we use this for lastModified check on URL based VFS handlers.
Correct, its testing whether if the URLConnection api can be used to detect file deletion. -
11. Re: File locking
adrian.brock Apr 22, 2008 12:50 PM (in response to alesj)"scott.stark@jboss.org" wrote:
Correct, its testing whether if the URLConnection api can be used to detect file deletion.
So we'll know when the JDK doesn't support it, but not when it
doesn't work in the VFS. :-)
Do you think it is a good idea to rely on implementation details of a particular JDK
rather than what it says in the spec? (rhetorical question :-) -
12. Re: File locking
starksm64 Apr 22, 2008 1:26 PM (in response to alesj)Right, we only know we are relying on an unstable implementation detail when this test fails. Taking over the handler implementation details to not rely a jdk version was the point of the urlconn-work branch of the vfs:
https://svn.jboss.org/repos/jbossas/projects/vfs/branches/urlconn-work/