There seems to be a regression with JDK1.6.
When I try to create a Javasource from a template using "DataObject.createFromTemplate"
the TaskScan would deadlock. See the attachment.
Created attachment 65186 [details]
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:
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
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?
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]
* JDO.copy does plain copy now
* Beans templates have been rewritten to FreeMarker
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
User: Jan Pokorsky <email@example.com>
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. ***