Has anyone else tested your producer / consumer test? We really need people to do that. Simple, expected, fixes are to move to getfirstchild/nextsibling and the tls approach (could use a pool for that too). But we need to make sure that at least one other person can repeat your findings before anything can be deemed to be solved.
I could repeat Olivers tests on a single cpu machine but I think yours require at least 2 cpus to cause the issues. (It may not even be the same issue of course). I can provide a patch for both fairly quickly but we really need at least two different setups for your tests to verify that the solution is complete. -----Original Message----- From: Vinh Nguyen (vinguye2) [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 02, 2007 10:05 PM To: [email protected] Subject: RE: EMPTY_DOC thread stability issues Any idea when the overall solution will be tested and an official patch released? I think this is a critical issue for mostly everyone. -----Original Message----- From: Oliver Waeldrich [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 12, 2007 2:47 AM To: [email protected] Subject: RE: EMPTY_DOC thread stability issues Hi all, I have checked the proposal of Chris and I really like it. I think the best way to proceed is to refactor the XmlUtils class a bit. The refatorisation of XmlUtils means that each Thread will have its own instance of a document builder. New documents are created by this instance. Therefore a new method getDocumentBuilder() is needed. Furthermore, the usage of createBuilder() in XmlUtils should be replaced by getDocumentBuilder() method. static final ThreadLocal tls = new ThreadLocal(){ protected Object initialValue() { // the method createBuilder needs to be synchronized return createBuilder(); } }; private static DocumentBuilder getDocumentBuilder() { return (DocumentBuilder)tls.get(); } This also means that the representations of EMPTY_DOC in the Muse code can be replaced with createDocument() without experiencing a big performance loss. With the changes proposed/done by Vinh I think the major parts of the problem should be solved. Thanks to Chris, Rich and Vinh for the fruitful discussion. Oliver -------- Original-Nachricht -------- > Datum: Thu, 6 Sep 2007 17:00:09 +0200 > Von: [EMAIL PROTECTED] > An: [email protected] > Betreff: RE: EMPTY_DOC thread stability issues > Hi all, > > @Oliver, I've tried running the tests but I get NPE's from both the > threadlocal version and the current version. Have I run something > incorrectly? > > java.lang.NullPointerException > at org.apache.xerces.dom.ParentNode.nodeListItem(Unknown Source) > at org.apache.xerces.dom.ParentNode.item(Unknown Source) > at > org.apache.muse.test.thread.local.TestEndpointReference.<init>(TestEnd > po > intReference.java:197) > at > org.apache.muse.test.thread.local.TestThread.run(TestThread.java:60) > java.lang.NullPointerException > at org.apache.xerces.dom.ParentNode.nodeListItem(Unknown Source) > at org.apache.xerces.dom.ParentNode.item(Unknown Source) > at > org.apache.muse.test.thread.local.TestEndpointReference.<init>(TestEnd > po > intReference.java:197) > at > org.apache.muse.test.thread.local.TestThread.run(TestThread.java:60) > > the shared epr and seperate docs versions shows no errors. > > The seperate doc one takes for ever, quite a performance hit on both > the synchronized for getLocalDoc, which shouldn't be necessary since > newInstance is threadsafe on DocumentBuilderFactory and the > createDocument. I replaced the getLocalDoc with : > > static final ThreadLocal tls = new ThreadLocal(){ > protected Object initialValue() { > DocumentBuilderFactory factory = > DocumentBuilderFactory.newInstance(); > factory.setNamespaceAware(true); > factory.setIgnoringComments(true); > try > { > return factory.newDocumentBuilder(); > } > catch (ParserConfigurationException error) > { > throw new > RuntimeException(error.getMessage(), error); > } > } > }; > > public static Document getLocalDoc() { > return ((DocumentBuilder)tls.get()).newDocument(); > } > > and it improved the performance considerably (equal with the current > solution, but correct). Creating new documentbuilder factories is > extremly expensive, jar lookups resource creation, class loading etc. > > cheers, > Chris > > PS A drop in replacement of a customised axis 1.4 - does namespaces > etc correctly - runs in 128 secs (half+ the speed of the current buggy > impl). If others are interested this version doesn't suffer threading > issues on read only, it just creates a few too many things but it > could be stripped down into a usable general dom. > PPS I'm going to start working with Vinhs tests now. > > -----Original Message----- > From: Vinh Nguyen (vinguye2) [mailto:[EMAIL PROTECTED] > Sent: Thursday, September 06, 2007 3:45 AM > To: [email protected] > Subject: RE: EMPTY_DOC thread stability issues > > My test case has been posted to JIRA Muse-270: > > https://issues.apache.org/jira/browse/MUSE-270 > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kanns mit allen: http://www.gmx.net/de/go/multimessenger --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
