ws-muse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Twiner (JIRA)" <j...@apache.org>
Subject [jira] Commented: (MUSE-270) EMPTY_DOC thread stability issues
Date Thu, 17 Apr 2008 09:01:22 GMT

    [ https://issues.apache.org/jira/browse/MUSE-270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12589875#action_12589875
] 

Chris Twiner commented on MUSE-270:
-----------------------------------

Hi All,

thanks Rich, thats great news.  I have found that, for robustness, I need to make further
changes to the patch.  It affects the TLS and in some cases interaction with tools that use
the Thread.setContextClassLoader.

We have found that in an osgi environment with Apache Cayenne (I'm sure there are other problem
areas and tools) the thread context classloader is being set for new threads, which conflicts
with normal OSGi usage.  As such the DocumentBuilderFactory.newInstance(); has the wrong classloader
and can fail.

I have changed the TLS code in my own code to:

  private static final ThreadLocal tls = new ThreadLocal(){
    	
    	ClassLoader cl = Thread.currentThread().getContextClassLoader();
    	
		protected Object initialValue() {

			//CTw fix for classloaders
			ClassLoader ct = Thread.currentThread().getContextClassLoader();
			Thread.currentThread().setContextClassLoader(cl);
			try{
		        //
		        // create the builder that will be shared throughout the process
		        //
		        DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
		        
		        //
		        // don't forget - turn on namespaces!!!
		        //
		        factory.setNamespaceAware(true);
		        
		        //
		        // we don't need comment nodes - they'll only slow us down
		        //
		        factory.setIgnoringComments(true);
		        
		        try
		        {
		            return factory.newDocumentBuilder();
		        }
		        
		        //
		        // this exception would be thrown if you have the DOM interfaces 
		        // but not the implementation
		        //
		        catch (ParserConfigurationException error)
		        {
		            throw new RuntimeException(error.getMessage(), error);
		        }
			} finally {
				// reset it
				Thread.currentThread().setContextClassLoader(ct);
			}
		}
	};

Since the very first time its used (via linking) should be acceptable I want to include it.
 However I'm looking for feedback on this and wether its desired etc.

cheers,
Chris

> EMPTY_DOC thread stability issues
> ---------------------------------
>
>                 Key: MUSE-270
>                 URL: https://issues.apache.org/jira/browse/MUSE-270
>             Project: Muse
>          Issue Type: Bug
>          Components: Utilities - General, QName, and XML, WS-Addressing and SOAP
>    Affects Versions: 2.0.0 M1, 2.0.0 M2, 2.0.0, 2.1.0, 2.2.0, 2.3.0
>         Environment: Impacts all platforms and configurations
>            Reporter: Rich Lucente
>            Assignee: Dan Jemiolo
>             Fix For: 2.3.0
>
>         Attachments: 270tsPatch2.txt, epr-tests.zip, muse_src.zip, MuseThreadSafety.zip,
WsnErrorsTest.zip
>
>
> This bug is being opened to track the EMPTY_DOC thread stability issue currently being
discussed on the muse-dev mailing list.  XmlUtils provides EMPTY_DOC as a scratchpad instance
of a DOM Document for creation of elements.  This has been shown to cause exceptions in a
multi-threaded environment.  The issue is compounded by the widespread use of EMPTY_DOC in
the code due to its convenience and the reduction in object creation when constructing XML
fragments.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: muse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-dev-help@ws.apache.org


Mime
View raw message