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 36617 - [completion] Code completion DB keeps refs to files after they have been unmounted
Summary: [completion] Code completion DB keeps refs to files after they have been unmo...
Status: VERIFIED WORKSFORME
Alias: None
Product: editor
Classification: Unclassified
Component: -- Other -- (show other bugs)
Version: 3.x
Hardware: PC Windows ME/2000
: P2 blocker (vote)
Assignee: issues@editor
URL:
Keywords:
Depends on:
Blocks: 20384
  Show dependency tree
 
Reported: 2003-10-15 14:22 UTC by schmig
Modified: 2007-11-05 13:44 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description schmig 2003-10-15 14:22:03 UTC 
To reproduce (on win2k):
 - mount a webcontext root
 - struts libs are mounted automatically
 (code completion thread starts parsing in 
background)

 - unmount the webcontext
 - struts libs are unmounted for you

- Try to delete struts libs in windows explorer
  - explorer complains about sharing violations

CounterExample:
  - disable tools->options->editor->editor 
settings->java editor->expert->update code 
completion database automatically

Situation is now unreproducable.
Comment 1 Petr Jiricka 2003-11-11 14:33:42 UTC 
If this is really true, then this is a serious issue that we would
like to get fixed - upgrading to P2. Editor team, can you please check
whether this also happens with regular Java jars (not in the context
of web applications)? 

See also issue 20384: if this issue is not fixed, then we can not fix
20384.
Comment 2 Martin Roskanin 2003-11-11 16:48:49 UTC 
Yes, it is reproducible also with regular jars. I have reproduced it
on NB 3.5. Hovever, I cannot reproduce this issue in the current dev
duilds (tested in NB dev build from 10.nov).
That's why I am resolving the bug as WORKSFORME.
Please verify. If you can reproduce it also in current dev build,
please reopen this issue. Thanks.
Comment 3 Petr Jiricka 2003-11-11 17:39:09 UTC 
Ok, I agree that this may be working well now, but I would still like
to know why and what happened exactly. Could it have something to do
with the JarFileSystem? Radek, can you comment?
Comment 4 rmatous 2003-11-12 09:33:06 UTC 
This  longterm problem with JarFileSystem was fixed after release
Netbeans 3.5. Now entries of archive are cached in memory or copied
into  temporary disc location (according to size of content) and
archiv is closed ASAP. This helped to close almost all issues assigned
to JarFileSystem including this one. On the other hand it had negative
impact on performance, because closing and reopening has its own
performance penalty (especially if you iterate content of JarFile and
parse content of entries).
Comment 5 schmig 2003-11-12 09:38:03 UTC 
Will this further affect the already very slow jsp compilation 
process (jasper spending forever looking for tag beaninfo classes in 
all mounted filesystems)?
Comment 6 rmatous 2003-11-12 09:51:45 UTC 
There is no problem if you just iterate entries and get FileObject
children recursively. But if you called getInputStream on every child
then you would be probably affected (naturally for hige jars like
rt.jar it would be significant).
Comment 7 Petr Jiricka 2003-11-12 10:38:00 UTC 
JSP compilation will go through a major rewrite, so it will be speeded up.
Comment 8 pfelenda 2003-11-20 16:53:24 UTC 
Verified in dev build 200311191900.

It is not reproducible with JAR file in dev build.