Thanks Pete -- I'll watch for that. I've already had some experience of
this sort of thing. Not nice.
[EMAIL PROTECTED] wrote:
>
> 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.
--
Andy Armstrong, Tagish
