tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ignacio J. Ortega" <na...@siapi.es>
Subject RE: Anyone know why the ISAPI redirector works how it does?
Date Sat, 23 Jun 2001 23:53:02 GMT
AFAIK only the request that need to be served by the Extension , that is
request that match the config present in UWM.P file are routed to the
extension , that runs in other priority thread, if you serve the Tomcat
request directly from the filter therad you are blocking the filter
thread in Tomcat.., and i repeat *ALL* the request served by an IIS
server are passed to ALL the filters..not only the Tomcat  one.. so if
the ISAPI extension were working like you are proposing you are blocking
the main server thread waiting for tomcat to serve the request, many
unrelated request will be slowed appreciably and the overall capacity of
the server will be greatly impacted...

I think there are good reasons to keep things as they are now...i dont
found a good reason , apart from code complexity , to do what you are
proposing ..but i'm not a ISAPI expert...I could be wrong.. i'm only
repeating to you the reasons Gal said to my many time ago.. you can
consult archives about May past year .. (i'm doing so now i wil try to
document it )

But i'm open to test and help in what you are proposing .. i'm not
trying to block you from doing so .. i'm only trying to left the old
code as it is, you can do what you are proposing in another directory in
jtc and call it with a funny name ( IISTHAR ? :), and we can test and
use it as an alternative .. if everything works as you expect .. good ..
if not we still have that good old code ... users need a escape way from
developers. :)

Saludos ,
Ignacio J. Ortega


> -----Mensaje original-----
> De: Andy Armstrong [mailto:andy@tagish.com]
> Enviado el: domingo 24 de junio de 2001 1:18
> Para: tomcat-dev@jakarta.apache.org
> Asunto: Re: Anyone know why the ISAPI redirector works how it does?
> 
> 
> Yes, but at the moment every IIS request gets passed to the 
> filter chain
> /and/ to the extension. What I'm proposing /must/ be faster. Please
> explain your objection.
> 
> "Ignacio J. Ortega" wrote:
> > 
> > I think this was done this way because every request on a IIS server
> > pass the entire Filter Chain, so a request that takes longer to be
> > served simply occupies the server thread more than necesssary ,
> > 
> > I'm -1 for this change ...
> > 
> > Saludos ,
> > Ignacio J. Ortega
> > 
> > > -----Mensaje original-----
> > > De: Andy Armstrong [mailto:andy@tagish.com]
> > > Enviado el: sábado 23 de junio de 2001 20:02
> > > Para: Tomcat Dev
> > > Cc: Gal Shachor
> > > Asunto: Anyone know why the ISAPI redirector works how it does?
> > >
> > >
> > > I've been looking at the source of the ISAPI redirector 
> (initially to
> > > get it to build again -- it seems to have broken), and
> > > wondering why it
> > > works the way it does.
> > >
> > > It provides both an HttpFilterProc and an HttpExtensionProc. The
> > > HttpFilterProc looks for incoming requests that are 
> elligable to be
> > > handled by Tomcat and, if it finds one, it rewrites the
> > > request so that
> > > it will be passed to the HttpExtensionProc for processing. From a
> > > cursory glance at the ISAPI documentation it seems that 
> this could all
> > > be handled in HttpFilterProc. Does anyone know what I'm missing?
> > >
> > > If there isn't a clear reason why it's implemented like this
> > > I might try
> > > and build a new ISAPI filter that works the same way as the
> > > Domino DSAPI
> > > filter. It should make request handling slightly faster, 
> simplify the
> > > code and might make it possible to have some source in 
> common between
> > > the Domino and IIS redirectors.
> > >
> > > --
> > > Andy Armstrong, Tagish
> > >
> 
> -- 
> Andy Armstrong, Tagish
> 

Mime
View raw message