axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lilantha Darshana <>
Subject RE: Transport Abstraction question
Date Thu, 06 May 2004 21:43:54 GMT
Decoupling between transport and XML parsing need to be considered.
There are two side of the coin when we think about performance, whether to
sacrifice the design 
quality and go for a poor design to improve performance. or achieve better
performance with a clean

Introduce a Ring Buffer Manager in between the transport layer and XML
payload reader/writer - 
to make it a producer/consumer model. Reading will block if the buffer does
not have enough
data for reading, this traps RingBufferManager to read data from transport
and fill the buffer.
Writing will synch data to the target. Transport layer will block until axis
writes output to
the RingBufferManager. 

For Xerces we can provide a InputSource, by using above model.
function calls like releaseBuffer(..) need to be encapsulated in the
then the interfacing between transport and axis is cleaner.


-----Original Message-----
From: Susantha Kumara []
Sent: Thursday, May 06, 2004 1:31 AM
To: axis-c-dev
Cc: Damitha Kumarage; Aleksander Slominski
Subject: Transport Abstraction question

Hi all,
I am working on Transport layer and Parser layer abstraction and got
following question,
At the moment Axis assumes that the receiving part of the transport layer
can behave in 2 ways.
1.       Some transport layers allocate memory buffers / fills them with
receiving data and gives to Axis.(see getBytes(..) function)
Ex : When using Expat parser
                  These transport layers want Axis to inform them when Axis
has finished using the given memory buffer.(see releaseBuffer(..) function)
2.       Some transport layers don't allocate memory buffers but will fill
the given buffers (from Axis).
Ex: When using Xerces parser.
But generally its VERY difficult for a XML parser to use the buffers given
by outside. Especially when the XML document is given in parts. 
In above 1st case too Expat internally copies all data passed to it into its
own buffer. That buffer inside Expat grows finally to the size of the whole
XML document. But if we get a buffer allocated inside Expat and pass it to
the transport layer to be filled and given back that would be more efficient
in terms of memory.
In above 2nd case Xerces allocates a buffer of around 48KB and passes it to
transport to be filled.
So It seems that there is no point of supporting case 1 as long as there is
no XML parser that is capable of efficiently parsing (without copying to its
other memory buffer) memory buffers allocated outside of the parser.
Those who have experience in writing an XML parsers will understand this
problem better.
So what about supporting only case 2 in the upcoming transport API ?.

View raw message