You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by "Ruchith Udayanga Fernando (JIRA)" <ji...@apache.org> on 2006/11/02 03:30:53 UTC

[jira] Commented: (AXIS2-1570) Rampart/Axiom is not thread safe

    [ http://issues.apache.org/jira/browse/AXIS2-1570?page=comments#action_12446428 ] 
            
Ruchith Udayanga Fernando commented on AXIS2-1570:
--------------------------------------------------

Please try the latest Rampart [1] with latest axis2[2]. This [3]
should fix the issue.

Thanks,
Ruchith

[1] http://ws.zones.apache.org/dist/rampart/nightly/
[2] http://ws.zones.apache.org/dist/axis2/nightly/
[3] http://svn.apache.org/viewvc?view=rev&rev=469841

> Rampart/Axiom is not thread safe
> --------------------------------
>
>                 Key: AXIS2-1570
>                 URL: http://issues.apache.org/jira/browse/AXIS2-1570
>             Project: Apache Axis 2.0 (Axis2)
>          Issue Type: Bug
>          Components: modules
>    Affects Versions: 1.0
>         Environment: WinXP, Tomcat 4/5, Websphere 5/6
>            Reporter: Johan Andersson
>
> The Axiom DOM (distributed with Axis 1.0) implementation seems to have some threading issues.
> The problem manifests itself as a nullpointer exception in org.apache.axiom.om.impl.dom.jaxp.DocumentBuilderFactoryImpl
> If I apply a moderate amount of load on the server so the number of http processor threads start increase the NPE will 
> happen all of the time whenever a piece of code tries to create a DocumentBuilder (for instance the WSDL parsing during deployment).
> I can reproduce this problem quite reliably.
> Nullpointer is caused by the originalDocumentBuilderFactory being null 
> --- snip ---
>     public DocumentBuilder newDocumentBuilder()
>             throws ParserConfigurationException {
>         /**
>          * Determine which DocumentBuilder implementation should be returned
>          */
>         return isDOOMRequired()
>                 ? new DocumentBuilderImpl()
>                 : originalDocumentBuilderFactory.newDocumentBuilder();
>     }
> --- snip ---
> I've tracked the problem to this piece of code in the org.apache.axiom.om.impl.dom.jaxp.DocumentBuilderFactoryImpl
> --- snip ---
>    public static void setDOOMRequired(boolean isDOOMRequired) {
>         String systemKey = DocumentBuilderFactory.class.getName();
>         if (isDOOMRequired) {
>             if (!isDOOMRequired()) {
>                 originalDocumentBuilderFactory = DocumentBuilderFactory.newInstance();
>                 originalDocumentBuilderFactoryClassName = originalDocumentBuilderFactory.getClass().getName();
>                 documentBuilderFactoryTracker.set(Boolean.TRUE);
>                 System.setProperty(systemKey, DocumentBuilderFactoryImpl.class.getName());
>             }
>         } else {
>             String currentFactoryClassName = DocumentBuilderFactory.newInstance().getClass().getName();
>             if (currentFactoryClassName != null && currentFactoryClassName.equals(DocumentBuilderFactoryImpl.class.getName())) {
>                 System.getProperties().remove(systemKey);
>                 if (originalDocumentBuilderFactoryClassName != null) {
>                     System.setProperty(DocumentBuilderFactory.class.getName(), originalDocumentBuilderFactoryClassName);
>                 }
>             }
>             documentBuilderFactoryTracker.set(null);
>             originalDocumentBuilderFactory = null;
>         }
>     }
> --- snip ---
> Trying to find away to resolve this I realise that the DOOM document builder factory implementation is in fact manipulating a JVM-wide
> system property in a multi-threaded environment (!) which besides the problem I am currently experiencing could lead to all sorts 
> of unwanted side-effects.
> As I don't want to allow this to happen I simply commented out the contents of the setDoomRequired() method hoping that Rampart could work
> with my default DOM instead and that I would only suffer some performance loss.
> I was wrong in that assumption as I encountered another problem: 
> StAXOMBuilder CHARACTERS: [org.apache.axis2.AxisFault: WSDoAllReceiver: security processing failed; nested exception is: 
> 	org.apache.ws.security.WSSecurityException: Cannot encrypt/decrypt data; nested exception is: 
> 	org.w3c.dom.DOMException: HIERARCHY_REQUEST_ERR: An attempt was made to insert a node where it is not permitted. 
> 	at org.apache.axis2.security.WSDoAllReceiver.processMessage(WSDoAllReceiver.java:183)
> 	at org.apache.axis2.security.handler.WSDoAllHandler.invoke(WSDoAllHandler.java:82)
> 	at org.apache.axis2.engine.Phase.invoke(Phase.java:381)
> 	at org.apache.axis2.engine.AxisEngine.invoke(AxisEngine.java:473)
> 	at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:445)
> 	at org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:284)
> 	at org.apache.axis2.transport.http.AxisServlet.doPost(AxisServlet.java:157)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:716)
> I compared the source of org.apache.axiom.om.impl.dom.jaxp.DocumentBuilderFactoryImpl in Axis 1.0 release and the latest in SVN
> http://svn.apache.org/viewvc/webservices/commons/trunk/modules/axiom/modules/axiom-dom/src/main/java/org/apache/axiom/om/impl/dom/jaxp/DocumentBuilderFactoryImpl.java?view=markup
> and can see no changes in how this is handled.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

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