axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Veithen <>
Subject Re: Performance Comparison
Date Tue, 04 May 2010 11:17:42 GMT
On Mon, May 3, 2010 at 17:19, Sanka Samaranayake <> wrote:
> On Sun, May 2, 2010 at 11:37 PM, Andreas Veithen
> <> wrote:
>> On Sat, May 1, 2010 at 09:12, Dennis Sosnoski <> wrote:
>>> Yes, I think it'd make much more sense to base a build-on-demand document
>>> model on the DOM API than to try to modify all the WSS4J and related code to
>>> use Axiom. Especially since Axiom is a mess and has had performance issues
>>> from the beginning (including using way too much memory as the model is
>>> expanded).
>> Each of the two approaches (porting WSS4J to Axiom / building a new
>> optimized Axiom+DOM implementation) have their pros and cons and I
>> think there is enough room for the two. They could even be
>> complementary provided that the new Axiom+DOM implementation has a
>> lower memory footprint and better performance.
>>> As a radical suggestion, how about just implementing a build-on-demand DOM
>>> subset suitable for use by WSS4J and other tools? This wouldn't need to
>>> support all the DOM operations (including those using NodeList).
>> That part is actually almost ready [1] (with more than just a subset
>> suitable for WSS4J). However, to work with Axis2 we have no other
>> choice than to support the Axiom API as well, at least the object
>> model part of it (while getting rid of what you called the "mess").
>> [1]
> Just for curiosity, have you done any performance comparison with your
> implementation with any other implementation ?

Not yet. BTW, do you know of any existing (performance) test suite
that tests WS-Security processing in isolation, i.e. without the need
for a full SOAP stack (my project is ready for integration with WSS4J,
but far from being ready to support Axis2)?

> Sanka
>>> Daniel Kulp wrote:
>>>> The "normal" way to traverse a DOM doesn't use the NodeList thing.   The
>>>> NodeList stuff isn't even threadsafe in Xerces.
>>> Actually, *no* access operations are threadsafe in Xerces. As far as I'm
>>> concerned that's a really bad design for general purpose use, ironically
>>> going back to the deferred node expansion feature that Xerces has on by
>>> default. It's always irked me that I have to use a synchronization lock
>>> around read-only operations with a (Xerces) DOM.
>>> That said, any form of build-on-demand document model is probably not going
>>> to be threadsafe. But for our purposes in using it with web services there's
>>> not much need for threadsafety.
>>>  - Dennis
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> --
> Sanka Samaranayake
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message