You are viewing a plain text version of this content. The canonical link for it is here.
Posted to muse-dev@ws.apache.org by "Vinh Nguyen (vinguye2)" <vi...@cisco.com> on 2007/10/02 22:04:32 UTC
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:oliver.waeldrich@gmx.de]
Sent: Wednesday, September 12, 2007 2:47 AM
To: muse-dev@ws.apache.org
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: Chris.Twiner@swisscom.com
> An: muse-dev@ws.apache.org
> 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:vinguye2@cisco.com]
> Sent: Thursday, September 06, 2007 3:45 AM
> To: muse-dev@ws.apache.org
> 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: muse-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: muse-dev-help@ws.apache.org
--
Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kanns mit allen: http://www.gmx.net/de/go/multimessenger
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-dev-help@ws.apache.org
RE: EMPTY_DOC thread stability issues
Posted by Ch...@swisscom.com.
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:vinguye2@cisco.com]
Sent: Tuesday, October 02, 2007 10:05 PM
To: muse-dev@ws.apache.org
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:oliver.waeldrich@gmx.de]
Sent: Wednesday, September 12, 2007 2:47 AM
To: muse-dev@ws.apache.org
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: Chris.Twiner@swisscom.com
> An: muse-dev@ws.apache.org
> 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:vinguye2@cisco.com]
> Sent: Thursday, September 06, 2007 3:45 AM
> To: muse-dev@ws.apache.org
> 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: muse-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: muse-dev-help@ws.apache.org
--
Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kanns mit allen: http://www.gmx.net/de/go/multimessenger
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-dev-help@ws.apache.org