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: | I18N - ide freezes after creating the second VWApp using win-31j encoding and ja_JP locale | ||
---|---|---|---|
Product: | obsolete | Reporter: | kaa <kaa> |
Component: | visualweb | Assignee: | _ deva <deva> |
Status: | VERIFIED FIXED | ||
Severity: | blocker | CC: | abadea, deva, jlahoda, kfrank, pjiricka, potingwu, sandipchitale |
Priority: | P2 | Keywords: | I18N |
Version: | 6.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: | |
Bug Depends on: | 117333, 117778 | ||
Bug Blocks: | |||
Attachments: |
Threads dump
New thread dump |
Description
kaa
2007-09-11 17:27:30 UTC
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 |