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: | Deadlock when called FileObjectQuery.getOwner from DataLoader.findPrimaryFile | ||
---|---|---|---|
Product: | platform | Reporter: | Peter Zavadsky <pzavadsky> |
Component: | Data Systems | Assignee: | Jaroslav Tulach <jtulach> |
Status: | RESOLVED WONTFIX | ||
Severity: | blocker | CC: | jglick, jtulach, tor |
Priority: | P3 | Keywords: | RANDOM, THREAD |
Version: | 4.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: | |
Bug Depends on: | 16389 | ||
Bug Blocks: | |||
Attachments: | Deadlock thread dump |
Description
Peter Zavadsky
2005-06-18 00:29:39 UTC
Created attachment 22775 [details]
Deadlock thread dump
Forgot to mention that this was experienced in our product which is build on top of NB 4.1. Now, when I looked closer, it seems to me it is a problem of the lookup impl. If you look at the "FolderRecognizer" the abstract lookup enters waiting state... but is never notified... because of "main" thread is waiting for lock on FileOwnerQuery... while the one is already taken by the "FolderRecognizer". Therefore passing to openide and increasing priority. I think the ability to determine project owner during data object loading should be supported, at least is it important in our tool. Maybe lookup owner can see something to improve, but I doubt it. In general I would say that calling FOQ from DataLoader.findPrimaryFile should be forbidden, since Datasystems is "lower level" than the Project API. It wouldn't have to be that way except for the fact that DS is still used for services Lookup. You should find some other way to accomplish what you want. We have a 90% workaround which we are using now, but it is not the perfect and not fully desired solution. To explain our scenario: We need to be able to determine the project ownership in the DO loading, which seems to me quite a legitimate requirement (in our sceanario we need to determine special project config file for which we have an object with special multiview, it makes sense only for the file whitin project). To the issue: I was also looking at the sources a bit. I am not sure, but it seems to me, this could be a similar issue, like with it was in DO locking (CC'ing Yarda, who was fixing that one). I.e. when you look at AbstractLookup impl, it uses the treelock field for its locking. But that it is a static field, i.e. shared by all instances. When you look at the stack traces, I guess, the instances which got locked (of the AbstractLookup class), seem to be different instances (one for project lookup, and the latter MIMEResolver lookup). At least it seems to me. I'd guess, using diff lock instances for the diff AbstractLookup instances might solve the issue. It needs to be checked. I hope you will be able to create a reproducible test case. First thing to suggest as a fix is to use getPrimaryFile().getFileSystem().isDefaultFileSystem() and if yes, then do not ask for the project. Should fix things for until better solution is found. Good tip. By the way I think J2ME developers had a similar question a while back, so you might want to consult with them. I guess there is simple solution, so I suggest wontfix. Otherwise I would make this depend on issue 16389 or at least its part. I would allow loader to say that it shall not recognize anything on systemfilesystem under Services/ folder. Probably by adding new contructor: DataLoader(String excludeSFSFiles); which would be initiated as: "Services/**" But that is too complex, for just one case that can be fixed by hand. It seems it might become extremelly important to be able for the DO Loader to recognize whether the file to be loaded belongs to some specific project. Otherwise there might happen the different DO's will be created for similar but different projects. E.g. for our project impl we create our DO for navigation.xml file, which shouldn't be loaded if it is inside NB jsf project. Reopening. Please, reconsider this. The datasystems layer should be insensitive to the project system layer, so I still think this should not be changed. Whatever you are trying to accomplish you can probably do some other way, e.g. using LogicalViewProvider to display a generic XMLDataObject in a special manner. In the long run, shoving complex semantics into the datasystems layer should be considered deprecated anyway. We need to provide multiview for that specific file in our project. That is not possible without having your own DataObject type, and providing all the needed cookie impls in it (editor support providing the multiview). Your suggestion doesn't work at all for that case. Why the DataSystem should be insensitive to the project level? Is there any valid reason for that? The above describes (at least) one reason for the opposite. Datasystems is lower level than project system. If the Multiview API (or XML Multiview API?) is incapable of letting you display a multi-view tab with custom content panes for a foreign data object, then that is an deficiency in that API, which you should file for the appropriate people to review (I don't know anything about it). |