ws-muse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vinh Nguyen (JIRA)" <j...@apache.org>
Subject [jira] Commented: (MUSE-270) EMPTY_DOC thread stability issues
Date Fri, 11 Jan 2008 09:36:34 GMT

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

Vinh Nguyen commented on MUSE-270:
----------------------------------

Looks like this issue is becoming very serious in high scale environments.  Because Muse uses
EMPTY_DOC in so many places and objects, the general result is that when multiple threads
attempt to access any object that's backed by EMPTY_DOC, various errors occur .  Mostly NullPointerExceptions
happen because retrieved data comes out null.

So the problem isn't really apparent just with notifications or EPRs.  I encountered the same
issue when multiple clients were calling Subscribe concurrently, and an NullPointerException
occurred in SubscribeResponse line 89 as indicated in the code below:

        String currentString = XmlUtils.getElementText(xml, WsnConstants.CURRENT_TIME_QNAME);
        String terminationString = XmlUtils.getElementText(xml, WsnConstants.TERMINATION_TIME_QNAME);
        try
        {
            if (currentString != null)
                _currentTime = XsdUtils.getLocalTime(currentString);
            
            if (terminationString != null)
                _terminationTime = XsdUtils.getLocalTime(terminationString);             <---
NullPointerException occurred here because terminationString was null !!!
        }

The workaround to this issue is to not allow mutilple Subscribes (or any other operation)
to execute concurrently, but this is not feasible.

This issue doesn't seem to happen in low-scale environments, or in single-processor machines
where threads don't truly run in parallel.  But it happens often in high-scale or multi-processor
machines. 

I think the real solution is to remove EMPTY_DOC completely.  There might be a performance
hit because now a new Document needs to be created for every object, but that's not as serious
as the multi-thread issue.  Also, trying to update code everywhere to synchronize access to
an object backed by EMPTY_DOC (which really is because of Xerces limitation of not being thread-safe)
is too much of a burden.  Muse is supposed to hide the fact that Xerces is used for DOM creation.



> 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: epr-tests.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