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.

Bug 169310 - 4200 ms - XmlMultiViewDataSynchronizer blocks save in AWT
Summary: 4200 ms - XmlMultiViewDataSynchronizer blocks save in AWT
Status: VERIFIED WORKSFORME
Alias: None
Product: javaee
Classification: Unclassified
Component: DD Editor (show other bugs)
Version: 6.x
Hardware: All All
: P3 blocker (vote)
Assignee: Denis Anisimov
URL: http://statistics.netbeans.org/except...
Keywords:
Depends on:
Blocks:
 
Reported: 2009-07-28 12:12 UTC by Jindrich Sedek
Modified: 2010-01-11 07:15 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter: 154342

Attachments
nps snapshot (9.47 KB, bin/nps)
2009-07-28 12:12 UTC, Jindrich Sedek 		Details
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Jindrich Sedek 2009-07-28 12:12:50 UTC 
Build: NetBeans IDE Dev (Build 090728)
VM: Java HotSpot(TM) Client VM, 11.3-b02, Java(TM) SE Runtime Environment, 1.6.0_13-b03
OS: SunOS, 5.11, x86

User Comments:
jsedek: I was editting web.xml file - the AWT thread got blocked while I was changing web-app header from DTD version 2.2 to use newer version 2.4 based on XML schema


Maximum slowness yet reported was 4200 ms, average is 4200
Comment 1 Jindrich Sedek 2009-07-28 12:12:56 UTC 
Created attachment 85321 [details]
nps snapshot
Comment 2 Jaroslav Tulach 2009-09-14 09:15:53 UTC 
The AWT thread is blocked in MasterFSFileObject.getOutputStream() this happens when someone holds on input stream for 
the same fileobject. Looking at the thread dump, I think that there is XmlMultiViewDataSynchronizer thread (running 
for 4s) which parses the content of the file object. This is lengthy operation as it also connects to network.

Possible fix might be to preload content of web.xml into memory (OK for files smaller than 100KB) and parse that 
instead of using directly the FileObject's input stream.
Comment 3 Petr Jiricka 2009-09-14 17:25:44 UTC 
Definitely we should not access network. Denis, can you please investigate? I see we correctly register web-app_3_0 and
web-fragment_3_0 XSDs in the entity resolver, so I don't know where the problem is. We don't register web-common_3_0,
could that be an issue?
Comment 4 Denis Anisimov 2009-09-14 18:25:04 UTC 
I see here version 2.4 mention.
Why do you talking about web-app_3_0 ?
Does version 2.4 uses web-app_3_0.xsd schema  ?

I see web-app_2_4.xsd schema file that is registered in EnterpriseCatalog.
This schema includes two more schema locations:
http://java.sun.com/xml/ns/j2ee/j2ee_1_4.xsd
http://java.sun.com/xml/ns/j2ee/jsp_2_0.xsd

Both schemes are in catalog also. 
But probably problem is in HTTP based schema locations.

I'm not sure.
Need to check it.
Comment 5 Denis Anisimov 2009-09-14 19:58:07 UTC 
I cannot reproduce it.
Could you please provide more details how you get this issue ?
Comment 6 Petr Jiricka 2009-09-14 21:17:09 UTC 
Sorry, I did not notice the version number.
Comment 7 Denis Anisimov 2009-09-23 07:27:54 UTC 
I cannot reproduce it.
There is no response from user and there were fixes in J2EE Catalog area
some time ago.
Probably it is fixed now.

Closing it.
Comment 8 Jindrich Sedek 2010-01-11 07:15:33 UTC 
v