Created attachment 14020 [details]
Thread dump

If you restart IDE after disabling and enabling module, it 'resets'
the issue so you can disable and enable it once after restart without
problem, but of course next disabling cause deadlock again.

Resume: After start of IDE you can safely once disable and enable
module. Next disable cause deadlock.

According to the stacktrace, this doesn't seem to be httpserver
problem, but a problem in openide, as it seems to get to some cycle
loop in URLMapper.

I'm working on this. 

Yarda, could you look at this. It is lookup or lookup.vs.datasystems
issue.

Couple of observations:
* httpserver registers its URLMapper in /Services subfolder of SFS.
Therefore disabling the module uninstall it and changes default lookup.
* in NetBeans 36beta (build 200402042050) this seems to work fine so
it looks like regression which happened recently.

If I had at hand daily builds of last month I would try to find when
this regression happened. That would help a lot. Is anybody at QA
willing to do that? I can do that myself on Monday when I'm in office.

Yarda, if the registration was moved to META-INF would it helped? (It
should be there anyway.) I guess it should because that would
eliminate FolderLookup usage. This could be quite safe fix at the
httpserver side.

This is serious issue but IMO not stopper for NB36. It should happen
only for modules providing URLMapper in /Services folder, which at the
moment in standard distribution is httpserver and javadoc module. And
anyway, how typical it is that users disable/enable/disable module in
one IDE session? I would record it just in release notes.

Registration in META-INF is of course more flexible and should be used
if one does not want the user to modify the content of the lookup in
options.

I do not see the deadlock. It is more infinite lookup. URLMapper
mapper is asked for something, it needs all registered mappers and
while creating the mappers, URLMapper is asked again and so on. 

As there were pretty significant changes between beta and release
(rev. 1.22) in URLMapper I suggest to include Radek in the loop.

Yes, it is infinite loop.

No, Radek could not cause it because his changes were related to URL
encoding semantics only.

Both code in URLMapper which is looking up registered URLMapper
implementations and code in NBClassLoader which is calling URLMapper
has been sitting there for some time without problem.

So my guess is that there was a change in lookup which caused this.
The problem happens after disabling httpserver module. First
suspicious thing is that disabling module should result in removal of
file from Services folder and there should not be any need for new
instance creation. And definitely it should not affect lookup of
URLMapper.class. Any idea? I was not following 36 relase much so I do
not know if there were any related changes.

There is no change in org.openide.util or org.openide.loaders related
to Lookup as can be verified by cvs diff -r
release36beta-BLD00402042050 -r release36

As there is no clear indication where the regression is and there
exist simple fix - use META-INF/services instead of /Services folder,
which is especially dangerous for URLMappers, I believe that if we
want to address this issue for 3.6 we should do it in httpserver module.

Well, if you transferred this one back to httpserver, then I'd say you
should file a separate issue for javadoc module as well.

I'll fix it in trunk and request a waiver for 3.6 as this happens in a
very rare case.

I tried the proposed fix - it doesn't solve the problem - loop is stil
there - I'll attach the new thread dump.

Created attachment 14074 [details]
Thread dump with proposed fix

I tried couple of builds and NetBeansIDE-dev-200402221900 still works
but NetBeansIDE-dev-200402241900 already throws StackOverflowError.
Sometimes I has to repeat disable/enable cycle twice or thrice. So I
tried to replace lib\openide-loaders.jar in newer build with the older
one and problem seems to disappear. And so then I looked at commit
logger for openide and only possibly relevant change which could cause
this is:

<http://openide.netbeans.org/servlets/ReadMsg?msgId=701197&listName=cvs>

by anebuzelsky. Tonda, could you please try the same what I did and
confirm that it is reproducible for somebody else then me? Could you
try to revert your change, create patch and try it with NB36 RC1
whether it was really caused by this change. Thx.

I will have a look at this and let you know.

I verified that the problem was introduced between 02221900 and 
02241900. My investigation and verification shows that the problem 
was not caused by my integration, but by an integration to 
XMLDataObject:

http://openide.netbeans.org/servlets/ReadMsg?msgId=701831&listName=cvs

Radime, it was your change.

Jesse, just told me that it is fixed in trunk. I tried it and it is
working. I suggest closing it as FIXED.

From the stacktraces that I see it looks to me that the problem is in
URLMapper and my integration only revealed it. I agree w/ David that
we can close it beacause it works in trunk. I don't want to rollback
the change for 3.6 until there is thorough analysis of what is really
wrong.

.

Waiver Request:

Description:
This problem occurs only when user disable/enable/disable httpserver
module. If user does that the IDE goes into infinitive loop which
looks like deadlock although it should eventually end with
StackOverflow exception. The could happen also for
disable/enable/disable of Javadoc module because bug is related to
URLMapper which is registered by both these modules. No other modules
should cause it.

Justification:
This is very uncommon user operation.

Workaround:
Restart IDE before second disable action.

Fix:
In trunk this does not happen because involved code was changed by
buildsys merge/cleanup.

I propose to just mention in Release Notes.

Waiver approved.

forgot to mark as verified