Please use the Apache issue tracking system for new NetBeans issues ( !!
Bug 60223 - Deadlock when called FileObjectQuery.getOwner from DataLoader.findPrimaryFile
Deadlock when called FileObjectQuery.getOwner from DataLoader.findPrimaryFile
Product: platform
Classification: Unclassified
Component: Data Systems
All All
: P3 (vote)
: 4.x
Assigned To: Jaroslav Tulach
Depends on: 16389
  Show dependency treegraph
Reported: 2005-06-18 00:29 UTC by Peter Zavadsky
Modified: 2008-12-22 20:36 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT

Deadlock thread dump (16.79 KB, text/plain)
2005-06-18 00:30 UTC, Peter Zavadsky

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Zavadsky 2005-06-18 00:29:39 UTC
See the attachment for detected deadlock.
It is probably not reproducible (Tor may adjust).

The question is whether it is incorrect to call
FileOwnerQuery#getOwner(FileObject) method from the DataLoader#findPrimaryFile
implementation (subclass).

There aren't documented any constraints upon the method call.
Comment 1 Peter Zavadsky 2005-06-18 00:30:09 UTC
Created attachment 22775 [details]
Deadlock thread dump
Comment 2 Peter Zavadsky 2005-06-18 00:30:47 UTC
Forgot to mention that this was experienced in our product which is build on top
of NB 4.1.
Comment 3 Peter Zavadsky 2005-06-20 17:14:49 UTC
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.
Comment 4 Jesse Glick 2005-06-20 20:39:42 UTC
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.
Comment 5 Peter Zavadsky 2005-06-20 21:22:09 UTC
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.
Comment 6 Jaroslav Tulach 2005-06-22 23:16:26 UTC
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. 
Comment 7 Jesse Glick 2005-06-22 23:41:25 UTC
Good tip. By the way I think J2ME developers had a similar question a while
back, so you might want to consult with them.
Comment 8 Jaroslav Tulach 2005-07-08 13:56:56 UTC
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:  
But that is too complex, for just one case that can be fixed by hand. 
Comment 9 Peter Zavadsky 2006-08-17 21:43:18 UTC
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.
Comment 10 Jesse Glick 2006-08-17 21:53:40 UTC
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.
Comment 11 Peter Zavadsky 2006-08-17 22:37:26 UTC
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.
Comment 12 Jesse Glick 2006-08-17 23:31:00 UTC
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).

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo