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.
Summary: | TaskScan causing deadlock in the IDE while creating java from template file | ||
---|---|---|---|
Product: | webservices | Reporter: | Ayub Khan <ayubskhan> |
Component: | Code | Assignee: | Milan Kuchtiak <mkuchtiak> |
Status: | RESOLVED FIXED | ||
Severity: | blocker | CC: | anebuzelsky, dbalek, jeff_rubinoff, jpokorsky, jtulach, tzezula |
Priority: | P2 | Keywords: | REGRESSION, THREAD |
Version: | 6.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: | |
Attachments: |
Thread dump
list of non FreeMarker java templates new list |
Description
Ayub Khan
2008-07-22 01:30:56 UTC
Created attachment 65186 [details]
Thread dump
Steps to reproduce. - Install NB6.5M2 - Set JDK home in the netbeans/etc/netbeans.conf to JDK 1.6 home - Start IDE - Create a new Web App `MyApp` - Open "Services" tab of the IDE - Drill down "Web Services"/Delicous/"Bookmarking Service"/posts/get/getPosts - drag and drop getPosts into MyApp/web/index.jsp -> There will be a deadlock immediately. I can reproduce even with JDK1.5 also ( I am using JDK1.5.0_13 on MacOSX 10.5) I guess we need to decide: Either someone using datasystems can call to java infrastructure or java infrastructure can call to datasystems. Anyway that is probably nothing datasystems can decided itself, this need to be done in java infrastructure or in clients that build on top of java infrastructure. My personal feeling is that the following call should be somehow eliminated: at org.openide.loaders.DataObjectPool.handleFindDataObject(DataObjectPool.java:156)\ at org.openide.loaders.DataLoader.findDataObject(DataLoader.java:401)\ at org.openide.loaders.DataLoader.findDataObject(DataLoader.java:374)\ at org.openide.loaders.DataLoaderPool.findDataObject(DataLoaderPool.java:482)\ at org.openide.loaders.DataLoaderPool.findDataObject(DataLoaderPool.java:440)\ at org.openide.loaders.DataObject.find(DataObject.java:492)\ at org.netbeans.modules.java.source.parsing.SourceFileObject.isOpened(SourceFileObject.java:362)\ at org.netbeans.modules.java.source.parsing.SourceFileObject.getCharContentImpl(SourceFileObject.java:370)\ at org.netbeans.modules.java.source.parsing.SourceFileObject.getCharContent(SourceFileObject.java:136)\ at org.netbeans.modules.java.source.parsing.SourceFileObject.getCharContent(SourceFileObject.java:82)\ at com.sun.tools.javac.main.JavaCompiler.complete(JavaCompiler.java:677)\ Dusane, Tomasi, any opinions? Interesting idea, in other words you say that the code cannot call datasystems with any lock. The mentioned code has to be done. There is another problem: Why the task lists run in time the initial scan is running => slowdowns IO, consumes memory, makes deadlocks? Who decides this? 1. For the proposed "the following call should be somehow eliminated": I would like to hear more about "somehow": unless there are is a new API to get the Document for opened file (FileObject) (or null if the file is not opened) without touching the DataObjects (which would be great, BTW), I do not see how we could eliminate this call. Any suggestions? Also, I am quite sure this wouldn't help - the Java infra runs arbitrary code inside the tasks (as provided by the clients). Unless we are somehow able to ensure that the the clients will not use DOs inside the tasks (which is impossible, and not reasonable currently, IMO), we may face a very similar deadlocks in the future anyway. 2. For the deadlock itself: I unfortunately, I do not see a reasonable way out of it. Best option might be to eliminate the JDO.renameFO. It is currently used in two places: "copy" and "createFromTemplate" (without freemarker). Not sure if it is needed in "copy" at all (refactoring handles this, right?). Or we could modify the DOs to handle this situation more gracefully. 3. The tasklist: I would like to ask the performance team to check performance of the tasklist itself and the performance of the tasklist providers. I am aware about tasklist providers which are taking Java files one by one and parsing them uncancellably (which is wrong on itself) even in projects are situations where it is quite obvious they will not provide any output (IIRC examples are J2EE persistence verifier and EJB verifier). I've talked with Honza Pokorsky about removing renameFo, the method is just used for non freemarker templates, converting the template to freemarker eliminates the call of renameFo. Like Honza Lahoda I am afraid of the performance of tasklist since it parses the sources with dependencies when the caches are not yet created. So maybe Honza could try to remove renameFO? So maybe Honza could try to remove renameFO? I can eliminate renameFO for JDO.copy. As jlahoda wrote it is covered by the refactoring module now. Removing renameFO for java templates means to converts them to FreeMarker. Otherwise they become broken. I will attach a list of old templates for full IDE. Created attachment 65554 [details]
list of non FreeMarker java templates
The previous list seems to be wrong. I have tried again and the list is a bit shorter. Created attachment 65567 [details]
new list
* JDO.copy does plain copy now http://hg.netbeans.org/main/rev/3de3f26ddf6c * Beans templates have been rewritten to FreeMarker http://hg.netbeans.org/main/rev/eb158e9936fe It is necessary to rewrite also websvc.saas.services.* and websvc.rest. See the new list. Reassigning to websvc. Integrated into 'main-golden', available in NB_Trunk_Production #344 build Changeset: http://hg.netbeans.org/main/rev/3de3f26ddf6c User: Jan Pokorsky <jpokorsky@netbeans.org> Log: #141093: removing semi-refactoring Fixed for websvc.saas.*, websvc.rest, see http://hg.netbeans.org/main/rev/33138aef1767 Milan can you fix the templates for websvc.wsitconf, websvc.core, see 65567 attachment for the templates *** Issue 128460 has been marked as a duplicate of this issue. *** |