I was also looking at Pull vs. Push parsers in a server environment using nio. There is an inherit problem with both when using any JAXB implementation for an API like I am doing. The server does not know when to stop reading the socket because it doesn't know the size of a Castor object. We temporarily have to specify the size(outside of the XML) of each object that is coming across to the server. This is kind of ugly but is impossible to solve until there is a truly Push parser out there where I can write data to it over and over and it fires events. The push parsers I saw were not push in the data sense of the word. They still did the reads just like the pull parsers. This is a huge problem when using nio where date should be pushed not pulled. If data is pulled, it has to know when to stop pulling otherwise you degrade to old io(So we use sizes inserted between the XML packets). If you solve this problem, let me know. I would be extremely interested.
thanks,
Dean
-------- Original Message --------
| Subject: | Re: [castor-dev] 5 times the performance if you want.... |
|---|---|
| Date: | Mon, 25 Nov 2002 07:18:49 -0700 |
| From: | Dean Hiller <[EMAIL PROTECTED]> |
| Reply-To: | [EMAIL PROTECTED] |
| To: | [EMAIL PROTECTED] |
| References: | <[EMAIL PROTECTED]> |
I am going to have to run the process of getting approval from our VP. I have done this once before without problems on my open source project so it shouldn't be a problem(I get access on a per project basis). This means I can't give the code yet.
I can give an overview. In Configuration.getParser(String), I just set the javax.xml.parsers.SAXParserFactory to the 1.4 parser(org.apache.crimson.jaxp.SAXParserFactoryImpl). I then returned a new XMLReaderAdapter wrapping that reader parser I had retrieved. I returned this before any of the configuration of the parser happened(Basically commented out all the code in getParser function. This naturally ignored all the configuration that would have been done. I might look into this later and see what types of configuration on the parser has so much of a performance effect. I would think the validation might be a hit, but I had turned that off originally and did not see a performance improvement. I will be looking into this further later on when I have time. I will send more mail when I narrow it down to what exactly is creating this performance hit.
Dean
John Weir wrote:
Dean, its probably just that's its late, but what exactly did you change - Can you send a Diff?John-----Original Message----- From: Dean Hiller [mailto:[EMAIL PROTECTED]] Sent: 23 November 2002 17:28 To: [EMAIL PROTECTED] Subject: [castor-dev] 5 times the performance if you want.... Just an FYI for those who need to improve performance. My group needed this as we needed to be in the microseconds per small message. Now we can proceed with Castor and I am very very happy to be able to use castor now. I was timing castor at 2.5 ms per small message. In the Configuration class, under getParser(String), I replaced the parser to 1.4.1_01's default by setting the javax.xml.parsers.SAXParserFactory property. This improved performance by 5 times. I think this happened not because of actually the act of switching Parsers, but due to the fact of all the configuration that was done to the original parser. The act of replacing it at this location in the code stopped all the configuration from happening. Hope this is helpful to others out there, Dean ----------------------------------------------------------- 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
