Keith, The threading issue, isn't really a problem since there is effectively one Unmarshaller created per SOAP request and there is also only one thread per SOAP request. However there may be several calls to Unmarshall per single request and this is where the gain can be got. I have tested the fix using a multithreaded SOAP client to make multiple request and everything was fine.
I can't see how getting the UnmarshllerHandler from the Unmarshaller would help me. The Handler is set on the XMLReader not the other way around so I don't see a way of overrinding the XMLReader in the Unmarshaller. Maybe that would be and Idea for future API changes ? Do you think there is any chance of wither of these solutions getting into the code base (given there significant performance boost). Thanks, Brian. p.s. I will keep you updated with any other performance improvements I find and what the end result in the comparison with CORBA turns out to be. -----Original Message----- From: Keith Visco [mailto:[EMAIL PROTECTED] Sent: 26 November 2003 20:00 To: [EMAIL PROTECTED] Subject: Re: [castor-dev] Unmarshalling - performance large XML extracts Brian, Are there any thread safety issues that you are aware of with caching the XMLReader? Also, you could always just get the UnmarshalHandler from the Unmarshaller and use your own cached XMLReader, without even having to modify Castor. --Keith "Brian Dillon (ext. 944)" wrote: > > Hi, > > We use Castor 0.9.5.2 and Axis 1.1 for providing SOAP services. Lately we > started doing some performance work on the area of SOAP and noticed that > Castor unmarshalling was one potential source of a bottleneck (using > JProbe). One of the tests in particular contains a list of Business Objects. > Each of these business objects are unmarshalled in turn via Axis passing the > XML extract to the unmarshaller. However taking a look at the > org.exolab.castor.xml.Unmarshaller.java it can be seen that there is a new > XMLReader constructed every time unmarshall(InputSource) is called. This > seems wasteful, especially if there are a large number of objects being > processed (in our case somewhere between 500 to 5000). > > If the Unmarshaller.java is changed to cache the XMLReader we see a > significant gain (See code extract below); > > public Object unmarshal(InputSource source) > throws MarshalException, ValidationException > { > //Fineos-BD 24/10/03 > //Try to have the parser/XMLReader cached ? > XMLReader reader = this._cachedXMLReader; > > //BD 25/10/03 XMLReader reader = null; > Parser parser = null; > > if(reader == null) { > //BD added if > //-- First try XMLReader > try { > reader = _config.getXMLReader(); > if (entityResolver != null) { > reader.setEntityResolver(entityResolver); > } > _cachedXMLReader = reader; > } > catch(RuntimeException rx) { > > Is there any reason why this is not currently done in the code base ? Should > it be done as it gives good performance improvements ? > > By the way I am already caching the ClassDescriptorResolver. I tested the > difference between using validation and no validation but this only results > in a performance gain of between 1% and 2% which is not really worth it. > > The overall intention is to get a SOAP service implementation to perform > somewhere near our current CORBA implementation. Currently we the above > change SOAP is just over 3 times slower. Without the change SOAP was 4.5 > times slower. Without caching the ClassDescriptorResolver SOAP was 5.36 > times slower. > > Thanks, > > Brian. > > ********************************************************************** > The information contained in this e-mail is confidential, may be privileged and is intended only for the user of the recipient named above. If you are not the intended recipient or a representative of the intended recipient, you have received this e-mail in error and must not copy, use or disclose the contents of this e-mail to anybody else. If you have received this e-mail in error, please notify the sender immediately by return e-mail and permanently delete the copy you received. This e-mail has been swept for computer viruses. However, you should carry out your own virus checks. > Registered in Ireland, No. 205721. http://www.FINEOS.com > ********************************************************************** > > ----------------------------------------------------------- > If you wish to unsubscribe from this mailing, send mail to > [EMAIL PROTECTED] with a subject of: > unsubscribe castor-dev ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
