That would work in the first instance. I also have some metabase management code to
set this up properly for an auto installer - let me know if you want it.
Cheers...Pete
-----Original Message-----
From: Ignacio J. Ortega [mailto:[EMAIL PROTECTED]]
Sent: Monday,25 June 2001 8:53
To: '[EMAIL PROTECTED]'
Subject: RE: Anyone know why the ISAPI redirector works how it does?
Hola a todos, Peter:
It seems from your messages that the actual architecture of the isapi
plugin is another form of the only filter solution ?
A easy way to solve it can be to simply separate the filter part from
the extension part of the isapi plugin without adding the thread pool?
could let us to run the extension in medium mode?...no need in a first
step to create the internal thread pool.. later we can add this capacity
..
What do you think ? , this can be a middle ground attack to the
problem??
Saludos ,
Ignacio J. Ortega
> -----Mensaje original-----
> De: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]
> Enviado el: lunes 25 de junio de 2001 0:26
> Para: [EMAIL PROTECTED]
> Asunto: RE: Anyone know why the ISAPI redirector works how it does?
>
>
>
> You're right - it can't for filters - hence why it defaults to "Low".
>
> A word of advice, if you are doing this on Win2K you also get
> into some hairy security issues and what is happenning under
> IUSR, IWAM etc. accounts. Keep it in mind if you start to
> see some strange behaviour in you tests.
>
> Cheers...Pete
>
>
> -----Original Message-----
> From: Andy Armstrong [mailto:[EMAIL PROTECTED]]
> Sent: Monday,25 June 2001 8:04
> To: [EMAIL PROTECTED]
> Subject: Re: Anyone know why the ISAPI redirector works how it does?
>
>
> [EMAIL PROTECTED] wrote:
> >
> > Hi, I'm a new, late starter on this thread...
> >
> > My understanding is that IIS runs about 15 threads and for
> filters it runs it on one of the threads, and for extension
> procs it uses the model defined in the application setup of
> the virtual directory (Low [iis thread], Medium [pool
> thread], High [isolated, app specific threads]). From what I
> can see of the Tomcat code, because it has the Filter and
> Extension call backs in the same DLL it will always default
> to Low (ie. as a filter).
> >
> > My understanding is that the best way to do the IIS/Tomcat
> integration is tricky - but worth it.
> >
> > You would:
> >
> > o Have a separate filter to do the absolute minimum to
> check whether the URI is for a Servlet - this would run on
> the IIS thread and then direct it to the Exension Proc.
> > o Have a separate DLL implementing the extension proc and
> have it run in the High protection model.
> > o In the extension proc you would implement the asynch call
> back model where in simple terms IIS passes the call to the
> Tomcat DLL, the Tomcat DLL then has its own pool of threads
> to process the request by releasing the IIS thread and
> holding a ref to a callback sig function so that when Tomcat
> has finished it sigs back to IIS that it is complete and IIS
> then takes over again. This is the way ASP works and makes
> sure you never get the dreaded "Server Busy" response back to
> the client because the scarce IIS threads are exhausted.
> >
> > Apart from that, I haven't thought about it ;-)
>
> Not much ;-)
>
> I'm surprised that it can choose which thread to use for filters -- is
> it not the case that filters are just called in the context
> of whichever
> thread is handling a particular request?
>
> I seem to be committed now to finding out empirically what's going on
> inside IIS and which approach will yield the best
> performance, both for
> requests delegated to Tomcat and for everything else the
> server's doing.
>
> I'll be sure to try the approach you suggest -- it certainly sounds
> reasonable.
>
> --
> Andy Armstrong, Tagish
>
>
> --------------------------------------------------------------
> ----------------
> This message and any attachment is confidential and may be
> privileged or otherwise protected from disclosure. If you
> have received it by mistake please let us know by reply and
> then delete it from your system; you should not copy the
> message or disclose its contents to anyone.
>
>
------------------------------------------------------------------------------
This message and any attachment is confidential and may be privileged or otherwise
protected from disclosure. If you have received it by mistake please let us know by
reply and then delete it from your system; you should not copy the message or disclose
its contents to anyone.
