This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 48736 - Project as a dependency causes file lock leaks
Summary: Project as a dependency causes file lock leaks
Status: RESOLVED DUPLICATE of bug 47919
Alias: None
Product: serverplugins
Classification: Unclassified
Component: Tomcat (show other bugs)
Version: 4.x
Hardware: PC Windows 7 x64
: P3 blocker (vote)
Assignee: Sherold Dev
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-09-09 05:04 UTC by _ gtzabari
Modified: 2015-10-26 17:17 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description _ gtzabari 2004-09-09 05:04:36 UTC
dev build 200409061800

I've got a web project whose "compiling sources"
properties include another project as a
dependency. The other project is a JAR file. If I
hit SHIFY-F11 to "clean and rebuild" the web
projects sometimes it works but sometimes it fails
to delete the JAR file in the other project it
depends on. It seems to me like Netbeans is
forgetting to close a file handle or release a lock.
Comment 1 Jesse Glick 2004-09-09 17:49:55 UTC
Probably a dupe, already fixed. If you can still reproduce in a
current dev build pls. reopen with precise steps to reproduce.

*** This issue has been marked as a duplicate of 48466 ***
Comment 2 _ gtzabari 2004-09-11 22:47:43 UTC
dev build 200409091800: this issue is still reproducable.

Create project A, a web project, with a classpath dependency on
project B, a library project. Hit SHIFT-F11 to clean and rebuild
project A. Run it. Try SHIFT-F11 again. The dependency B is going to
have its files locked and cannot be deleted. Maybe tomcat is at fault?
Comment 3 Jesse Glick 2004-09-12 00:55:01 UTC
Milan please check if you can reproduce... if so, need some sort of
Windows-specific tool to track down the owner of the file lock, not
sure what that is; will need to reassign to someone with such tools.
Could be a problem in Ant, Tomcat, the javac parser, etc.
Comment 4 Milan Kubec 2004-09-13 15:42:35 UTC
Reproducible for me:

init:
deps-clean:
init:
deps-clean:
Deleting directory E:\work\testprojects\JavaLibrary1\build
Deleting directory E:\work\testprojects\JavaLibrary1\dist
clean:
do-clean:
Deleting directory E:\work\testprojects\WebApplication1\build
E:\work\testprojects\WebApplication1\nbproject\build-impl.xml:354:
Unable to delete file
E:\work\testprojects\WebApplication1\build\web\WEB-INF\lib\JavaLibrary1.jar
BUILD FAILED (total time: 1 second)

Don't know any tool Jesse mentioned.
Comment 5 _ gtzabari 2004-09-13 15:53:50 UTC
There is FileMon --
http://www.sysinternals.com/ntw2k/source/filemon.shtml -- which lists
*all* file accesses. You could concievably dump logs to disk, then
filter them until you catch the last person opening the file but not
closing it.

CAVEAT: The log is *huge* so using this approach is by no means easy.

Another approach would be to somehow poll the locking state of the
file at different times (i.e. before and after Tomcat is invoked) and
isolate when it occurs.
Comment 6 Jesse Glick 2004-09-13 15:56:28 UTC
David, can you check it and reassign as needed?
Comment 7 _ gtzabari 2004-09-13 15:59:14 UTC
Actually, if you guys can reproduce this under Linux, maybe it has
better tools for detecting file locks than Windows.
Comment 8 Jesse Glick 2004-09-13 16:21:43 UTC
Unix does not have mandatory file locks, just Windows. However you can
sometimes find whether the JVM has a given file open (e.g.
memory-mapped) using the Gnome process monitor, which can give you a
hint that may apply to Windows.
Comment 9 David Konecny 2004-09-14 14:43:08 UTC
It is Tomcat who holds the file opened and which after some time
release it. I can see that in my monitoring program. 
Comment 10 Petr Jiricka 2004-09-14 15:08:01 UTC
Ok, Tomcat is known to have this problem. So David and Gili, are you
saying that this only happens when Tomcat in the IDE is running, or
does it sometimes happen also when Tomcat is not running?
Comment 11 David Konecny 2004-09-14 15:51:18 UTC
Yes, it happens when built jar is deployed to Tomcat (i.e. Web project
is Run). After that I can see that external java process in which
Tomcat runs has opened the jar built by project and holds it opened.
Randomly after some time the file is closed and disappear from the
list. When it is opened by Tomcat the build in IDE fails with "Unable
to delete file".
Comment 12 _ gtzabari 2004-09-14 18:08:14 UTC
Hmm, even if it a known Tomcat issue we should really try to address
it somehow -- using a workaround or whatever else. Right now you need
to restart Netbeans every time you want to clean & build your project.
Comment 13 Jesse Glick 2004-09-14 18:12:59 UTC
Perhaps belongs in j2eeserver module rather than web, I don't know.
Comment 14 Petr Jiricka 2004-09-14 18:15:21 UTC
Changed category to tomcatint. Gili, does it help to stop Tomcat in
the Runtime tab? That should be a valid workaround. Or just to wait
for 20 seconds or so? Tomcat should just release the jars itself.
Comment 15 zikmund 2004-09-14 18:23:33 UTC
Tomcat restart helps. Waiting 20 secs helps only sometimes :(.
Comment 16 _ gtzabari 2004-09-14 18:26:01 UTC
Also, if there is a Tomcat Bugzilla associated with this we should
post it here so we can followup on it and see when they fix it. Petr,
you mentioned this was a known issue, from where?
Comment 17 Sherold Dev 2004-10-01 10:11:19 UTC
Marking as duplicate of issue 47919.

*** This issue has been marked as a duplicate of 47919 ***
Comment 18 rxdelta 2015-10-26 06:52:54 UTC
This was not only on web projects
I have some projects, They are Java Libraries (none of them is web application), and this is their dependencies:

Project `Lib` have no dependency
project `Pack1` depends on `Lib`
project `Pack2` depends on `Pack1`, `Lib`
project `Pack3` depends on `Pack4`, `Lib`
project `Pack4` depends on `Lib`
project `Final` depends on `Pack1`, `Pack2`, `Pack3`, `Pack4`, `Lib`

When I do "Clean and Build" on "Final", SOMETIMES, It would terminate by this error:

ant -f D:\\code\\Final clean jar
init:
Deleting: D:\code\Final\build\built-clean.properties
deps-clean:
Updating property file: D:\code\Final\build\built-clean.properties
Pack1.init:
Pack1.deps-clean:
Updating property file: D:\code\Final\build\built-clean.properties
Lib.init:
Lib.deps-clean:
Created dir: D:\code\Lib\build
Updating property file: D:\code\Final\build\built-clean.properties
Deleting directory D:\code\Lib\build
Lib.clean:
Deleting directory D:\code\Pack1\build
Pack1.clean:
Pack2.init:
Pack2.deps-clean:
Updating property file: D:\code\Final\build\built-clean.properties
Pack3.init:
Pack3.deps-clean:
Updating property file: D:\code\Final\build\built-clean.properties
Pack4.init:
Pack4.deps-clean:
Updating property file: D:\code\Final\build\built-clean.properties
Deleting directory D:\code\Pack4\build
D:\code\Final\nbproject\build-impl.xml:1471: The following error occurred while executing this line:
D:\code\Final\nbproject\build-impl.xml:1521: The following error occurred while executing this line:
D:\code\Pack2\nbproject\build-impl.xml:1450: The following error occurred while executing this line:
D:\code\Pack2\nbproject\build-impl.xml:1479: The following error occurred while executing this line:
D:\code\Pack3\nbproject\build-impl.xml:1450: The following error occurred while executing this line:
D:\code\Pack3\nbproject\build-impl.xml:1479: The following error occurred while executing this line:
D:\code\Pack4\nbproject\build-impl.xml:1446: Unable to delete file D:\code\Pack4\dist\Pack4.jar
BUILD FAILED (total time: 3 seconds)


Note that I did not execute any of these project in netbeans or any other place, even I closed Windows File Explorer, there is no application working with my code files (Except Netbeans), and SOMETIMES, in any steps, `Clean and build` Process raised with error title: `Unable to delete SOMEPROJECT.jar`. the more dependencies, the more errors
Condition: Netbeans 7.3.1; OS: Windows 7; CPU: Intel Core i7 3770
Comment 19 _ gtzabari 2015-10-26 17:16:00 UTC
rxdelta,

Do not reopen/modify closed issues. Please open a separate issue and reference the old issue there, if needed.

*** This bug has been marked as a duplicate of bug 47919 ***