messages.log has no exceptions

Please use Ctrl-Break to get the thread dump and attach to this issue.

I can reproduce it always. And the thread dump is very consistent in insync; attached.
    at org.netbeans.modules.web.jsf.JSFConfigEditorSupport$1.save(JSFConfigEditorSupport.java:78)

Created attachment 48592 [details]
Threads dump

The problem seems to between:

"AWT-EventQueue-1" prio=6 tid=0x31140400 nid=0x670 waiting on condition [0x31eaf000..0x31eafc14]
   java.lang.Thread.State: WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <0x0589e0d8> (a java.util.concurrent.locks.ReentrantLock$FairSync)

and

"AWT-EventQueue-1" prio=6 tid=0x31140400 nid=0x670 waiting on condition [0x31eaf000..0x31eafc14]
   java.lang.Thread.State: WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <0x0589e0d8> (a java.util.concurrent.locks.ReentrantLock$FairSync)
	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:778)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1114)
	at java.util.concurrent.locks.ReentrantLock$FairSync.lock(ReentrantLock.java:201)
	at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:262)
	at org.netbeans.api.java.source.JavaSource.runUserActionTask(JavaSource.java:544)
	at org.netbeans.modules.web.struts.StrutsConfigUtilities.getActionServlet(StrutsConfigUtilities.java:235)
	at org.netbeans.modules.web.struts.StrutsConfigUtilities.getConfigFilesFO(StrutsConfigUtilities.java:317)

and

"Default RequestProcessor" daemon prio=2 tid=0x32c30c00 nid=0xd80 waiting on condition [0x3383f000..0x3383fb14]
   java.lang.Thread.State: WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <0x0589e0d8> (a java.util.concurrent.locks.ReentrantLock$FairSync)
	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:778)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1114)
	at java.util.concurrent.locks.ReentrantLock$FairSync.lock(ReentrantLock.java:201)
	at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:262)
	at org.netbeans.api.java.source.JavaSource.runUserActionTask(JavaSource.java:544)
	at
org.netbeans.modules.j2ee.metadata.model.api.support.annotation.AnnotationModelHelper.runJavaSourceTask(AnnotationModelHelper.java:159)

which are all waiting on the same object: 

<0x0589e0d8> (a java.util.concurrent.locks.ReentrantLock$FairSync)

Insync's thread is simply waiting for the AWT thread to execute invokeAndWait().

Assigning to Petr for initial evaluation.

Andrei, could you look at this? Thanks.

The deadlock is between the "Loading ModelSet" thread and the AWT event thread.The former is holding the Retouche javac
lock (because of JavaSource.runUserActionTask()) and is trying to display a dialog, which requires waiting for the AWT
event thread. OTOH, the AWT thread is trying to acquire the javac lock.

The culprit is the Loading ModelSet thread, which should not do UI work while holding the javac lock.

Andrey (kaa) (not Andrei)

please run in zh locale to make sure its not a pseudo localization situation
or if you know that its not, please add to bug report information.

ken.frank@sun.com

On Solaris10 with zh_CN locale the problem exists.

Deva, this does not appear to be our problem directly. We simply calling some 

org.netbeans.modules.visualweb.insync.models.FacesConfigModel.save()

API which in turn calls:

org.netbeans.modules.web.jsf.JSFConfigEditorSupport$1.save()

which is trying to show a dialog (correctly) using invokeAndWait(). The real issue may be that - why does :

org.netbeans.modules.web.struts.StrutsConfigUtilities.getActionServlet

call

org.netbeans.api.java.source.JavaSource.runUserActionTask(). 

on AWT thread. In fact there is a warning if some code does it.

Let us discuss this today.

Other alternative may that

org.netbeans.modules.web.jsf.JSFConfigEditorSupport$1.save()

calls the dialog creation using SwingUtilities.invokeLater(). Thus the calling thread will be able to continue and return.

I means to say:

"calls the dialog creation and display using SwingUtilities.invokeLater()."

After discussing this more with Deva we think as of now the best solution is to call the creation and display of the
dialog in org.netbeans.modules.web.jsf.JSFConfigEditorSupport.saveCookie.new SaveCookie() {...}.save() using the
SwingUtilities.invokeLater() mechanism. That is because the dialog being shown is simply a warning dialog to let the
user know of the invalid XML warning. The return value of the dialog is not being used to take different action.

As such Insync code does not have any control over when this dialog is shown or not shown.

As an aside, it may be that the code in org.netbeans.modules.web.struts.StrutsConfigUtilities.getActionServlet() should
not call the org.netbeans.api.java.source.JavaSource.runUserActionTask() on AWT thread. 

The org.netbeans.modules.web.jsf.JSFConfigEditorSupport.saveCookie.new SaveCookie() {...}.save() cannot be invoked using
SwingUtilities.invokeLater() mechanism, because the save cookie calls saveDocument(), where is checked the encoding. If
there is not appropriate encoding, then user is asked, how to save the document. 

IMHO the main problem is that you are trying to save faces config inside JavaSource.runUserActionTask(). 

Deva can you have a look at this please?

As per my debugging, the dialog is shown because an exception is thrown while getting the DOM document. The exception 
thrown in JSFConfigDataObject.getDomDocument() is as follows
"org.netbeans.modules.schema2beans.Schema2BeansNestedException: Failed to create the XML-DOM Document.  Check your XML 
to make sure it is correct. Invalid byte 1 of 1-byte UTF-8 sequence."

Why the XML document is invalid when the project is created with a different encoding? We will not run into this 
deadlock if the document were correct in the first place.

BTW, we have enclosed the visual web modeling in a JavaSource.runUserActionTask() in order to improve performance(to 
address a P1 issue)

Andrey, see last sentence please.

I can't comment at all on lower level things, but just want to mention that for nb6
there is concept of a project encoding, which can be changed by user, and then
subsequent projects created with that encoding.

also, there is creation of the jsp files, in which the project encoding is used to seed
the jsp encoding tag.

it might be that some info about encoding is not being commmicated sometwhere or that
some code might assume encoding of the locale user is in vs the project encoding
which might be different, or visa versa, since in this case the project encoding starts as
utf-8 and then is changed to the encoding the user is in.

Andrey, now that the fix to the seeding of vwp jsp files is done, please try this scenario
on a recent built, and examine the jsp files of each project and note here what they are.

Po-Ting and Quy on vwp team can tell more about the feq things in vwp, since there were other issues
about this solved before.

ken.frank@sun.com

the issue is reproducible with 0920 build on XP.

Created attachment 49582 [details]
New thread dump

I can't comment on the schema2beans exception, I don't know what causes it. Perhaps it will be uncovered once the
deadlock is fixed.

While trying to reproduce the deadlock I got a very similar one, which happened even earlier in the FacesModelSet
initialization process, even before save() was called on the JSF file's SaveCookie. See the attached thread dump. It
pretty clearly shows that:

- the JSF encoding problem (if it is a problem at all) is a separate one. There is nothing about JSF in this deadlock.
- insync does too much under the javac lock (inside JavaSource.runUserActionTask()). For example: why does
FacesContainer need to be initialized under the javac lock? Why does CurrentProject need to initialize the project field
in its constructor, when this field will be overwritten by the first call to getCurrentProject()?

Seems the issue is more complicated:
if the project encoding is not the default, no vwp project can be created at all since ide freezes.
I checked with java project, bpel and ejb module for the first project. If needed I can file a new issue.

On the latest build, when just creating a simple web project without any framework, I see the following warning in the
console! Is that an issue?

WARNING [org.netbeans.api.java.source.JavaSource]: JavaSource.runUserActionTask called in AWT event thread by:
org.netbeans.modules.web.struts.StrutsConfigUtilities.getActionServlet(StrutsConfigUtilities.java:235)

Quy recently fixed the FileEncodingQuery related functionality of JsfJspDataObject. That may have fixed the specific
issue of invalid XML error dialog. Deva, can you try this again?

Reduced the scope of user action task responsible for modeling of a newly created project. The latest deadlock 
reported by Andrea will be addressed with my fix.

Have discussed this bug with Petr Pisl, he has agreed to look into the following two issue
1) Why the exception "org.netbeans.modules.schema2beans.Schema2BeansNestedException: Failed to create the XML-DOM 
Document" occurs?
2) Using a different thread to run the user action task instead of AWT thread in StrutsConfigUtilities

is this still considered an i18n issue, that is that it happens only in some other locale,

and/or when the default project encoding of nb6 projects is changed to some other encoding ?

or is this a general problem with the 2nd visualweb app even in en locale ?

I just want to be clear for our issue tracking.

ken.frank@sun.com

So now there are two problem in our side as Deva mentioned:

>1) Why the exception "org.netbeans.modules.schema2beans.Schema2BeansNestedException: 
> Failed to create the XML-DOM Document" occurs?

I entered different issue #117333. The problem is that a databobjects (as JSFConfigDataObject) has check whether the xml
file is well-formed before saving. If the editor is not open, then the check takes an InputStream from FileObject.
Bacause there is not implemented FileEncodingQuery for the dataobject, the InputStream of the FileObject is in the
project encoding, which doesn't have to fit for all characters and the check fails due to impossibility parsing the xml
file in the wrong encoding. Opening and closing such file in editor is OK, because it takes the encoding from the
dataobject and it returns the right encoding. So the problem will be solved when FEQ will be implemented.

> 2) Using a different thread to run the user action 
> task instead of AWT thread in StrutsConfigUtilities

It is not right solution to move just StrutsConfigUtilities.getConfigurationFiles... outside AWT thread, because there
is someone waiting for the result. The action which pick up the configuration file has to be moved outside AWT. In this
case the root action is displaying Configuration files in the logical view, which has obtain the configuration file list
outside AWT.

Andrei is going to solve the issue with obtaining configuration files.

I tried computing the children of the Configuration Files node in a background thread. It breaks the Find in Projects
action. With a web.xml file open in the editor, invoke Find in Projects (Ctrl+Shift+1). The web.xml node under Web
Pages/WEB-INF will be selected. This is incorrect, the web.xml node under Configuration Files should have been selected.
But the Configuration Files nodes is just in the middle of computing its nodes, so all the action sees is a "please
wait" node. What's worse, if you invoke Find in Projects again, it will select web.xml under Configuration Files,
because the nodes have been computed by now. So the action behaves inconsistently, which is even worse.

I confirm I can't reproduce the second deadlock anymore (the one I reported in desc21). Would be nice to see the commit
log of the fix. I still can reproduce the first deadlock.

I can still reproduce the first deadlock. I still maintain its root cause is the way insync works, and I'm beginning to
be quite dissapointed by how you guys seems to ignore all arguments. Again: the schema2beans exception is caused by
FileEncodingQuery not being implemented for faces-config.xml, and this issue is being dealt with on our side. However,
understand that you can indirectly call SwingUtilities.invokeLater() under the javac lock, which is deadlock-prone! Even
if we fix the encoding problem, your code can still deadlock if the user changes the faces-config.xml encoding manually
and forgets to remove the invalid characters.

You need to avoid saving faces-config.xml under the javac lock. I don't see the reason you need to do that anyway.

To clarify, we did the entire modeling during new project creation in a user action task to address the performance 
issue((with a new user directory). In fact retouche team member suggested us to enclose our modeling in a user action 
task so that it can be done fast without being interrupted by back ground scanning thread. Also, we were not aware of 
the fact that faces config cannot be modified with javac lock. The only thing we are aware is that user action task 
should not be done in AWT thread. Hence we wanted the AWT thread issue to be addressed in the struts module.

It was the peformance concern that we did not want to change our logic. Given that there is no other alternative to 
address this problem, we did some measurements with and without enclosing our modeling with a user action task and 
found that there is very minor degradation in performance for new project creation with a new user dir. Since deadlock 
is an important issue to be addressed, we have decided to remove the enclosing task.

Checking in FacesModelSet.java;
/cvs/visualweb/insync/src/org/netbeans/modules/visualweb/insync/models/FacesModelSet.java,v  <--  FacesModelSet.java
new revision: 1.23; previous revision: 1.22
done

verified: looks ok on Mac, build 1010, ja and zh

looks ok on XP.ja_JP: build 1010