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
There aren't documented any constraints upon the method call.
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:
which would be initiated as:
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
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).