axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glen Daniels <>
Subject RE: Parsing stuff
Date Thu, 19 Apr 2001 18:13:13 GMT

This looks pretty good, James, and is in a lot of ways just about identical
to what I did. :)

A few comments:

* Using thread.suspend(), thread.resume(), etc. directly isn't a good plan.
You want to be using condition variables and explicit synchronization across
the two threads - your code as it stands has places where deadlock can
occur.  (example: what if we're in
MessageElementFactory.getHeaderElement(int) and the parseThread runs really
quickly after you resume() it - in fact so quickly that it's already
resume()d our thread before we suspend()...)

* Too much context switching; I'd rather not suspend() and resume() for each
element if you don't need to (i.e. if you're looking for something, why

* I'm not sure how much we gain with the "symbol table" approach as opposed
to just recording what we get directly.

My code (attached) synchronizes, uses a slightly different model for
recording, and lets the parse thread keep going until it finds the desired
element (only supports headers at the moment, though).  On the other hand,
yours is more complete in several areas, and I like the "factory" much
better than my more tight binding to SAX.  We should probably merge the two
and check the sucker in, after we make sure that everything is pluggable


> -----Original Message-----
> From: James M Snell []
> Sent: Thursday, April 19, 2001 12:29 AM
> To:
> Subject: Re: Parsing stuff
> Well... coincidentally, in between implementing a simple 
> version of the 
> serialization/deserialization architecture for the current 
> Axis codebase 
> and writing a new article for developerWorks, I took some 
> time last night 
> to throw together the attached bit of code that does the same 
> thing.  This 
> code is pretty basic, and since I'm not going to claim to be 
> an expert in 
> Java thread management, may not be completely right on.  But, 
> it does work 
> (though the object model does need a bit of cleanup)
> This code gives us:
>     1. Streaming support
>     2. Lazy parsing
>     3. Much better performance (for a simple SOAP envelope 
> with 2 headers 
> and a single body element, I was noticing speeds averaging about 10 
> milliseconds for each loop in the code contained in the 
> class 
> (see the zip file) compared to an average of 40-50 
> milliseconds per loop 
> using a DOM approach (I'm using Xerces2 in nonvalidating mode, btw).
> I wrote this last night between 11:00pm and 2:00am so please 
> be gentle 
> with your flames ;-) 
> - James Snell
>      Software Engineer, Emerging Technologies, IBM
> (online)
> (offline)
> Please respond to 
> To:     "''" <>
> cc: 
> Subject:        Parsing stuff
> I've got a version of the multi-thread SAX parse working, 
> though it needs 
> a
> bit of cleanup.  It's mostly a proof-of-concept.
> I'm going to see if I can make some improvements, clean it up 
> a bit, and
> post it to the list tomorrow for review.
> Basically, it does exactly what we talked about.  When you create a 
> Message
> around an InputSource, it spawns a thread which parses the <envelope>
> element, makes sure it looks OK, and then suspends.  When 
> anyone asks for
> something from the Message (i.e. getHeaderByName(QName)), the parsing 
> thread
> wakes up and runs until it finds the desired thing or runs out of XML
> (initially this just means getting to the end of the headers).  As it 
> goes,
> it creates SOAPHeader objects, which contain records of the SAX events
> inside them, suitable for replaying to any ContentHandler.  
> Meanwhile the
> other thread (the one that made the getHeaderByName() call) 
> blocks until 
> the
> parse is complete.
> Glen Daniels
> Macromedia
> Engineering Manager
>                                 Building cool stuff for web developers

View raw message