The use of EMPTY_DOC was an attempt to avoid creating a new Document every time we wanted to copy or create small fragments of XML. This happened a lot during the request/response process, so the creation of these factory objects was not insignificant. Of course, you are right about the threading issue, so I guess we're out of luck there.
I am setting aside Friday of this week to go through current JIRA items and
apply all patches that have been submitted, close any issues that are
recommended for closure, and sort unscheduled items into 2.3 if necessary.
Sorry for the delay.
Dan
[EMAIL PROTECTED]
08/24/2007 04:37 To
PM [email protected]
cc
Please respond to Subject
[EMAIL PROTECTED] EMPTY_DOC thread stability issues
e.org
Use of EMPTY_DOC (an instance of an empty DOM Document element within
class XmlUtils) among multiple threads causes unpredictable results.
While testing a messaging service that uses the Apache Muse WS-N
implementation, I noticed that 4-6 messages in a 1000 were being dropped.
Notification messages were being sent at a rate of 20 per second. Where
the messages were dropped, the following stack trace occurred:
2007-08-24 15:27:58,031 ERROR [STDERR] Aug 24, 2007 3:27:58 PM
org.apache.muse.util.LoggingUtils logError
INFO: There was an error while processing a request:
[ID = 'NoMessageContent'] The NotificationMessage XML does not have a
Message element. All messages must have a message payload associated with
them.
org.apache.muse.ws.notification.impl.SimpleNotificationMessage.<init>
(SimpleNotificationMessage.java:117)
org.apache.muse.ws.notification.impl.NotificationMessageSerializer.fromXML
(NotificationMessageSerializer.java:46)
org.apache.muse.core.serializer.ArraySerializer.fromXML
(ArraySerializer.java:126)
org.apache.muse.ws.notification.impl.NotifyHandler.fromXML
(NotifyHandler.java:62)
org.apache.muse.core.SimpleResource.invoke(SimpleResource.java:368)
org.apache.muse.core.routing.SimpleResourceRouter.invoke
(SimpleResourceRouter.java:290)
org.apache.muse.core.platform.axis2.AxisIsolationLayer.invoke
(AxisIsolationLayer.java:136)
org.apache.muse.core.platform.axis2.AxisIsolationLayer.handleRequest
(AxisIsolationLayer.java:88)
sun.reflect.GeneratedMethodAccessor102.invoke(Unknown Source)
sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:324)
org.apache.axis2.receivers.RawXMLINOutMessageReceiver.invokeBusinessLogic
(RawXMLINOutMessageReceiver.java:88)
org.apache.axis2.receivers.AbstractInOutSyncMessageReceiver.receive
(AbstractInOutSyncMessageReceiver.java:39)
org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:493)
org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest
(HTTPTransportUtils.java:319)
22 more...
All of the messages did in fact have a message payload associated with
them. After further investigation I noticed that
AxisEnvironment.convertToDOM is calling XmlUtils.createElement(QName)
which uses the common EMPTY_DOC Document instance. Sharing EMPTY_DOC
among multiple threads is not safe.
I've also encountered this issue while attempting to set the producer
reference on a NotificationMessage. The code actually performs a deep
copy of the EndpointReference class which also relies on EMPTY_DOC. I
hacked a work-around within my code that avoided use of EMPTY_DOC and
resolved the issue.
A grep for EMPTY_DOC against the code base turned up over 70 instances of
its use. That does not count methods that use it that are called by other
methods, so the actual usage is much higher. I'm going to open a JIRA bug
against this issue and submit patches for it.
Related to that, I've submitted patches for other issues (MUSE-240,
MUSE-241) over a month ago that have not been committed. The patch for
MUSE-240 also resolves MUSE-225. Please let me know the appropriate
process for non-committers to have patches applied to the code base. When
I submitted the JIRA issues they showed up in this mailing list, but is an
explicit email more appropriate? Let me know how best to proceed.
Thanks!
Rich Lucente
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<<inline: graycol.gif>>
<<inline: pic30643.gif>>
<<inline: ecblank.gif>>
