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>(TestEndpo
> 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>(TestEndpo
> 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]
