If you're not very tied in to using JAXP, consider using the org.apache.xerces.parsers.CachingParserPool and the associated XNI pipeline. Ive observed significantly faster creation as compared to JAXP and there are significant memory advantages you can achieve through pipeline configuration that are really inconvenient to do through JAXP. Of course these are Xerces internal APIs, and should be used with the cautionary note that the developers give.
On Fri, 27 Aug 2004, Rick Bullotta wrote: > Thanks for the suggestion, Chris. That's probably our next step (parser > pool). > > We've reduced the parser creation time somewhat using two system properties: > > javax.xml.parsers.DocumentBuilderFactory > > ...set to ... > > org.apache.xerces.jaxp.DocumentBuilderFactoryImpl > > ..and.. > > javax.xml.parsers.SAXParserFactory > > ...set to... > > org.apache.xerces.jaxp.SAXParserFactoryImpl > > > > -----Original Message----- > From: Christopher Ebert [mailto:[EMAIL PROTECTED] > Sent: Friday, August 27, 2004 1:06 PM > To: [EMAIL PROTECTED] > Subject: RE: Xerces overriding JDK XML parser - Classloader Issues? > > > Hi, > > I think DocumentBuilder objects can be re-used, so you could use > an object pool, build some number of them on startup and reuse them... > > Chris > > > -----Original Message----- > From: Rick Bullotta [mailto:[EMAIL PROTECTED] > Sent: Friday, August 27, 2004 08:50 > To: [EMAIL PROTECTED] > Subject: Xerces overriding JDK XML parser - Classloader Issues? > > Here's our scenario: > > We're running JDK 1.4.2_05 with the latest Xerces/Xalan in the JRE's > lib/endorsed directory. We run servlets (on New Atlanta's ServletExec > engine) and are experiencing some serious performance issues when > instantiating a parser instance from within a servlet using: > > DocumentBuilderFactory dFactory = DocumentBuilderFactory.newInstance(); > dFactory.setNamespaceAware(true); > DocumentBuilder dBuilder = dFactory.newDocumentBuilder(); > > We've been working with the New Atlanta folks trying to sleuth it out, > and the issue seems to be that somewhere in the factory code are > getResourceAsStream() calls, probably to load property or configuration > files. These calls seem to be performed every request, rather than > loaded once, and when there are lots of JARS in the classpath, this > operation can be VERY VERY expensive searching the JARS. > > Question is: > > Is there any way to bypass this frequent loading using either: > > a) JVM command line parameters > b) Setting a property through code > c) Some type of singleton object > > Many thanks! > > Rick Bullotta > CTO > Lighthammer Software (http://www.lighthammer.com) > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
