thanks for the tip, looking at my test case code, I only called Unmarshaller.setValidation(false); This did not improve the performance of the unmarshaller. Only my changes did by swapping in a new XMLParser and some other minor changes. Low and behold as I look them up I can't find the view of castor where I made the performance improvements. Serves me right for not following though on that task. I multitask too much.
Out of curiosity, are you planning on using nio? or making your implementation easy to use nio, where I just keep calling a write method on the JAXB implementation? I know it would help alot of server developers.
thanks,
Dean
Dennis Sosnoski wrote:
Dean Hiller wrote:
here is one of the messages. I do now have VP approval to give code. I just need to dig it up sometime. I have not gotten around to narrowing what caused the hit down. I just have a fix. When I work on it again, I will send you the code. I don't have the time to dig it up right now and I would like to test it again before I send it. Last testing was on 0.9.4.1.
I suspect the effect of your change was just to make sure validation was turned off. As I understand it, there are actually two separate ways of controlling validation in Castor. The first is the pair of properties org.exolab.castor.validation and
org.exolab.castor.marshalling.validation, which are both true by default. The second is the actual Marshaller and Unmarshaller objects, which each have validation flags that are true by default. You need to call setValidation(false) on each of these to turn off validation. I don't know exactly what the connection is between the property setting and the Marshaller and Unmarshaller object settings, but in my tests I made sure all were set false. If validation is turned on there'll be a substantial performance hit, especially for unmarshalling small documents.
Can one of the developers comment on this? The control of validation was one of the areas I found confusing in the Castor documentation.
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.
What you're talking about is not a problem with the parsers, it's a consequence of XML's design. The only way a parser can tell that an XML document has been completely processed is when it reaches the end of the input stream. This means you can't just stream XML documents over a connection - you end up with one big (and invalid) document. There are ways around this that don't involve sending document sizes - wrapping the stream and looking for a particular start or end pattern, then reporting an end of stream to the parser from your wrapper, for instance - but they're not going to work for all valid XML documents. Giving the size of each document in advance is the simplest approach, so that a wrapper for the input stream on the receiving end can just use byte counts to see when to report an end of stream to the parser.
- Dennis
----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
