axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glen Daniels" <>
Subject Re: Some source
Date Wed, 25 Apr 2001 12:30:08 GMT
> > One quick concern: Its not clear to me whether the two-thread
> > approach is still in use. If so I think we still have a non-starter.
> > Sorry .. no +1 in that case.
> Once the code is integrated, I will do some performance measurements.  I
> too am a bit concerned as I believe that the Xalan crew is moving away from
> a two thread model as they found the task swapping overhead obliterated any
> of the overhead benefits that they expected to receive.

Damn you guys are early risers. :)

The deal is as follows, Sanjiva - I'm currently using the two thread approach
due to lack of alternatives.  The threading stuff (and the actual SAX parser)
will be cleanly modularized in the version I'll check in tomorrow.  So
everything is based on SAX-style events, but you should be able to easily
switch the system to:

1) Using a pull parser like XPP, with a SAX adapter layer, or
2) Using Xerces-2, which apparently allows you to do a pseudo-pull model (each
call to parse() processes one event, then returns, remembering where the parser

Either of these approaches is pretty clearly better long term than the dual

Sam, to answer the q about threading, threading is absolutely not allowed in an
EJB context, and many other app servers don't really want servlets creating
bunches of threads either.  One of the big wins of an enterprise-level app
server is that a lot of the hard work about synchronization and load balancing
and resource management has been done for you in the middleware.  If all the
resources are being nicely handled by the framework, it can throw somewhat of a
wrench in things to start opening your own threads, db connections, etc.  We
need to be sensitive to these concerns if we want Axis to be nicely embeddable
(which is critical for me).


View raw message