Description Paul Slauenwhite 2005-12-06 13:54:48 EST

WI1 (112371): Reuse org.xml.sax.XMLReader when de-serializing Common Base Event XML fragment/document.

Note: This defect covers work item 1 of enhancement #112371
(https://bugs.eclipse.org/bugs/show_bug.cgi?id=112371) for performance and memory 
improvements for the three producer Common Base Event implementations.

Currently, a new org.xml.sax.XMLReader object is created and configured before a 
Common Base Event XML fragment/document is de-serialized using the EventFormatter 
class in both the EMF and non-EMF Java Common Base Event implementations.  For example, 
the use case of importing a Common Base Event XML log file results in 88.5% of the 
total  for de-serializing the Common Base Event XML log file.  Specifically, 
creating the XML parser during de-serialization accounts for 26% of the total .  
Also, creating the XML reader during de-serialization accounts for 61% of the total .  
Finally, when the XML reader is created during de-serialization, a SAXParser is created and 
initialized accounting for 44% of the total .

Although the test environment is using a JDK (e.g. IBM JDK) that ships 
the Xerces parser, some JDKs (e.g. Sun JDK v1.4.x) ships a proprietary XML 
Parser implementation (e.g. Crimson) which often deviates from the XML Parser 
specification.   For example, although the XML Parser specification specifies 
that "once a parse is complete, an application may reuse the same org.xml.sax.XMLReader 
object, possibly with a different input source", the TPTP and EMF Teams have 
found this not to be entirely correct for all XML Parser implementations.  As 
such, we have opted to create a new instances of the org.xml.sax.XMLReader and 
org.eclipse.hyades.logging.events.cbe.util.SAXEventHandler on each invocation 
of the 
org.eclipse.hyades.logging.events.cbe.util.associationEnginesFromCanonicalXMLDoc
() and org.eclipse.hyades.logging.events.cbe.util.eventsFromCanonicalXMLDoc() 
methods.  

The proposed fix (see attach) contains the overhead of 
synchronizing each call to the above static methods as well as the memory 
consumption of a static lock object.  Ultimately, more investigation is needed 
to determine the residual side affects of the proposed fix (see attach) and 
possibly the design and implementation of an alternative fix to achieve similar 
performance benefits without the high risk of a functional breakage in certain 
run-times. 


Sizing (PW):
 
Design:        0.25 
Code:          0.25 
Test:          0.5 
Documentation: 0.0
-------------------
Total:         1.0