RE: Status of the current IIS ISAPI Redirector for Tomcat
This is a TC Users list so I will redirect the conversation to how do we use SPD in a Tomcat implementation TO Wit: what you're asking is there support for SPDY Protocol in any version of TOMCAT? Since SPDY requires the use of SSL/TLS (with TLS extension NPN) Which version TC Container supports TLS/NPM? *gruss* Martin __ > From: kpreis...@apache.org > To: users@tomcat.apache.org > Subject: RE: Status of the current IIS ISAPI Redirector for Tomcat > Date: Sat, 15 Feb 2014 15:00:44 +0100 > > Hi Angel and Bilal, > > thank you for your replies. > > > > -Original Message- > > From: Angel Java Lopez [mailto:ajlopez2...@gmail.com] > > Sent: Saturday, February 15, 2014 11:59 AM > > To: Tomcat Users List > > Subject: Re: Status of the current IIS ISAPI Redirector for Tomcat > > > > Very interesting! > > > > Yes, managed code is the path to follow. > > > > First idea non-blocking IO (from C# client side): use the new async/await > > for the communication. But force to use the new .NET framework and Visual > > Studio. And await is a wait on the current threads: > > > > http://msdn.microsoft.com/en-us/library/hh750082.aspx > > > > Maybe, a "node.js" approach, with a callback: > > > > http://stackoverflow.com/questions/16894907/creating-asynchronous- > > methods-with-task-factory-and-callback > > and only .NET 4.0: > > http://msdn.microsoft.com/en-us/library/dd537612(v=vs.100).aspx > > > > I don't still see the value of await: it blocked the current thread. I > > guess it is better to use a callback > > A "await" on a Task in C# should internally return the current thread back to > a threadpool, and use a callback on another thread to continue execution of > the method when the Task is finished, so that threads are not blocked when > waiting e.g. for an I/O operation to complete. For a full utilization of > asynchronous I/O, one would not only have to use async read/write operations > when forwarding the request to Tomcat, but also async flush the response body > at IIS to the client (and async read the request body). Although the .Net > HttpResponse also seem to have BeginFlush() and EndFlush() methods that apply > the old-style async programming pattern, in the SPDY Redirector (see below) > I'm using Task.Factory.FromAsync(...) to convert these Begin/End-Methods into > one that returns a Task, so that it can be integrated into the existing > Task-based async code. > > For async flush and read operations at IIS to work, one will need to create > an async module (IHttpModule, but use context.AddOnBeginRequestAsync() > methods to add event handlers) or an async handler (derived from > HttpTaskAsyncHandler). > > This is the approach that I use on a draft of an SPDY redirector that can > already be tested with Jetty (but not yet with Tomcat), see [1]. After > switching from blocking I/O to async methods, the number of threads of the > IIS apppool (w3wp.exe) was greatly reduced when having a slow output producer > (servlet) on the Jetty side, and a fast client connecting to IIS (but should > also work for the more likely scenario: A fast output producer (Jetty) and a > slow client); as with blocking I/O, the IIS threads would spend most of their > time with doing nothing, whereas with the async approach, they can do other > things meanwhile. > > This approach suits the idea of a multiplexing SPDY as you can send multiple > requests on a single SPDY connection, so it doesn't block resources like > sockets or threads for the duration of an request. With SPDY, it should also > be possible to forward Websocket connections which is AFAIK not possible with > AJP. > > > > > > Angel "Java" Lopez > > @ajlopez > > > > > > On Fri, Feb 14, 2014 at 9:26 PM, Bilal S wrote: > > > > > Konstantin, > > > > > > ==> > > > You raise good points. I have run into similar issues and thus created my > > > own project outside the Apache foundation three years ago (BonCode). It > > is > > > a C# based AJP connector. It can currently be used with Tomcat, JBOSS, > > > Jetty. From support requests I am surmising that is currently bundled with > > > software from a few manufacturers including: EMC, CSC, Siemens and > > others > > > instead of ISAPI redirector. > > > > > > Thus, I do encourage the update of the current IIS connection mechanism > > to > > > a more up-to-date method. Using a managed code mechanism is the way > &g
RE: Status of the current IIS ISAPI Redirector for Tomcat
Hi Angel and Bilal, thank you for your replies. > -Original Message- > From: Angel Java Lopez [mailto:ajlopez2...@gmail.com] > Sent: Saturday, February 15, 2014 11:59 AM > To: Tomcat Users List > Subject: Re: Status of the current IIS ISAPI Redirector for Tomcat > > Very interesting! > > Yes, managed code is the path to follow. > > First idea non-blocking IO (from C# client side): use the new async/await > for the communication. But force to use the new .NET framework and Visual > Studio. And await is a wait on the current threads: > > http://msdn.microsoft.com/en-us/library/hh750082.aspx > > Maybe, a "node.js" approach, with a callback: > > http://stackoverflow.com/questions/16894907/creating-asynchronous- > methods-with-task-factory-and-callback > and only .NET 4.0: > http://msdn.microsoft.com/en-us/library/dd537612(v=vs.100).aspx > > I don't still see the value of await: it blocked the current thread. I > guess it is better to use a callback A "await" on a Task in C# should internally return the current thread back to a threadpool, and use a callback on another thread to continue execution of the method when the Task is finished, so that threads are not blocked when waiting e.g. for an I/O operation to complete. For a full utilization of asynchronous I/O, one would not only have to use async read/write operations when forwarding the request to Tomcat, but also async flush the response body at IIS to the client (and async read the request body). Although the .Net HttpResponse also seem to have BeginFlush() and EndFlush() methods that apply the old-style async programming pattern, in the SPDY Redirector (see below) I'm using Task.Factory.FromAsync(...) to convert these Begin/End-Methods into one that returns a Task, so that it can be integrated into the existing Task-based async code. For async flush and read operations at IIS to work, one will need to create an async module (IHttpModule, but use context.AddOnBeginRequestAsync() methods to add event handlers) or an async handler (derived from HttpTaskAsyncHandler). This is the approach that I use on a draft of an SPDY redirector that can already be tested with Jetty (but not yet with Tomcat), see [1]. After switching from blocking I/O to async methods, the number of threads of the IIS apppool (w3wp.exe) was greatly reduced when having a slow output producer (servlet) on the Jetty side, and a fast client connecting to IIS (but should also work for the more likely scenario: A fast output producer (Jetty) and a slow client); as with blocking I/O, the IIS threads would spend most of their time with doing nothing, whereas with the async approach, they can do other things meanwhile. This approach suits the idea of a multiplexing SPDY as you can send multiple requests on a single SPDY connection, so it doesn't block resources like sockets or threads for the duration of an request. With SPDY, it should also be possible to forward Websocket connections which is AFAIK not possible with AJP. > > Angel "Java" Lopez > @ajlopez > > > On Fri, Feb 14, 2014 at 9:26 PM, Bilal S wrote: > > > Konstantin, > > ==> > > You raise good points. I have run into similar issues and thus created my > > own project outside the Apache foundation three years ago (BonCode). It > is > > a C# based AJP connector. It can currently be used with Tomcat, JBOSS, > > Jetty. From support requests I am surmising that is currently bundled with > > software from a few manufacturers including: EMC, CSC, Siemens and > others > > instead of ISAPI redirector. > > > > Thus, I do encourage the update of the current IIS connection mechanism > to > > a more up-to-date method. Using a managed code mechanism is the way > to go > > in my opinion. > > In the long run SPDY may also be of interest for the same purpose. The > more > > choices the better. > > > > The following are differences already in existence with BonCode and in > > response to your extensive writing, only read on if you are curious:: > > > Thank you for you detailed response, this is very helpful. > > > 6. > > > > > > As far as I can see, the ISAPI redirector uses blocking I/O when > > > forwarding requests to Tomcat. > > > > > > This means when a slow client sends a request to IIS which gets > forwarded > > > to Tomcat, and Tomcat starts to send the response, in the IIS worker > > > process at least 1 Thread will be dedicated to this request as long as it > > > is not finished. This means if 500 slow clients concurrently send > > requests > > > to IIS (which get forwarded), IIS has to create 500 threads in the >
Re: Status of the current IIS ISAPI Redirector for Tomcat
Very interesting! Yes, managed code is the path to follow. First idea non-blocking IO (from C# client side): use the new async/await for the communication. But force to use the new .NET framework and Visual Studio. And await is a wait on the current threads: http://msdn.microsoft.com/en-us/library/hh750082.aspx Maybe, a "node.js" approach, with a callback: http://stackoverflow.com/questions/16894907/creating-asynchronous-methods-with-task-factory-and-callback and only .NET 4.0: http://msdn.microsoft.com/en-us/library/dd537612(v=vs.100).aspx I don't still see the value of await: it blocked the current thread. I guess it is better to use a callback Angel "Java" Lopez @ajlopez On Fri, Feb 14, 2014 at 9:26 PM, Bilal S wrote: > Konstantin, > > > > On Fri, Jan 24, 2014 at 2:06 PM, Konstantin Preißer >wrote: > > > Hi all, > > > > for my Java Servlet web applications which run on Tomcat (currently > > 8.0.0-RC 10) on various Windows Server OSes (currently Windows Server > 2012 > > R2), I use the ISAPI Redirector to forward requests from IIS to Tomcat > over > > AJP. I use IIS as primary web server because I also host other websites > > that use different technologies like ASP.Net and PHP (and because IIS > > allows to run web applications as different processes as different user > > accounts, and because I can configure the SSL settings over IIS, and so > on). > > > > The ISAPI Redirector has its job done well in the past and currently I'm > > still using it. Note that I'm only using it to forward requests from a > > single IIS instance to a single Tomcat instance, but not for > load-balancing > > or other features. > > > > > > However, over the time I found some issues which seem to result from the > > changes that Win Server, IIS and other components have experienced over > > time, which I wanted to list here and see how these could be changed. > > > > A possibility that I see is to use an ASP.Net (C#) based redirector > > instead of an ISAPI based redirector as that will have a number of > > advantages - see below. > > > > > > > ==> > You raise good points. I have run into similar issues and thus created my > own project outside the Apache foundation three years ago (BonCode). It is > a C# based AJP connector. It can currently be used with Tomcat, JBOSS, > Jetty. From support requests I am surmising that is currently bundled with > software from a few manufacturers including: EMC, CSC, Siemens and others > instead of ISAPI redirector. > > Thus, I do encourage the update of the current IIS connection mechanism to > a more up-to-date method. Using a managed code mechanism is the way to go > in my opinion. > In the long run SPDY may also be of interest for the same purpose. The more > choices the better. > > The following are differences already in existence with BonCode and in > response to your extensive writing, only read on if you are curious:: > > > > > > 1. > > > > The ISAPI Redirector seems to be quite complicate to configure. You have > > to: > > 1) place the ISAPI redirector DLL in some arbitrary path (the docs > suggest > > to place them in your Tomcat\bin directory) > > > ==> not needed > > > 2) create a virtual directory in your IIS web application which points to > > this path > > > ==> not needed > > > 3) change the handler settings for the virtual directory to allow to > > execute ISAPI dlls > > > ==> not needed > > > 4) add the ISAPI redirector DLL to the list of CGI and ISAPI restrictions > > in IIS > > > ==> not needed > > > 5) add the ISAPI redirector DLL to your web app as ISAPI filter > > > ==> not needed > > > 6) create some registry entries at HKLM\Software\Apache Software > > Foundation\Jakarta Isapi Redirector\1.0 to specify the path of the > virtual > > directory, path to configuration files etc. > > > ==> not needed > > > 7) create configuration files (uriworkersmap.properties, > > worker.properties) and but them in some arbitrary path (the docs suggest > to > > place them in your Tomcat\conf directory) > > > > ==> not needed, configurations are done via the IIS UI and/or an xml > config file > > > > I see a few problems here. > > First, you have to place the ISAPI redirector DLL in some external > > arbitrary path. This can introduce additional maintenance issues as you > > always have to remember this when e.g. moving the server. Because the > docs > > suggest to place them in your Tomcat\bin directory, you might delete that > > file by mistake when you delete your Tomcat installation and create a new > > one. > > The same is true for the config files - if you place them in your Tomcat > > directory, you might delete them when you change your Tomcat config. > > > > Normally, these files do not belong to Tomcat, but to the ISAPI > > redirector, so I would expect to place them somewhere in your IIS web > > application. > > > > E.g, ASP.Net web applications have a "web.config" file in their root > > directory for configuration, and a "bin" directory where .Net assemblies
Re: Status of the current IIS ISAPI Redirector for Tomcat
Konstantin, On Fri, Jan 24, 2014 at 2:06 PM, Konstantin Preißer wrote: > Hi all, > > for my Java Servlet web applications which run on Tomcat (currently > 8.0.0-RC 10) on various Windows Server OSes (currently Windows Server 2012 > R2), I use the ISAPI Redirector to forward requests from IIS to Tomcat over > AJP. I use IIS as primary web server because I also host other websites > that use different technologies like ASP.Net and PHP (and because IIS > allows to run web applications as different processes as different user > accounts, and because I can configure the SSL settings over IIS, and so on). > > The ISAPI Redirector has its job done well in the past and currently I'm > still using it. Note that I'm only using it to forward requests from a > single IIS instance to a single Tomcat instance, but not for load-balancing > or other features. > > > However, over the time I found some issues which seem to result from the > changes that Win Server, IIS and other components have experienced over > time, which I wanted to list here and see how these could be changed. > > A possibility that I see is to use an ASP.Net (C#) based redirector > instead of an ISAPI based redirector as that will have a number of > advantages - see below. > > > ==> You raise good points. I have run into similar issues and thus created my own project outside the Apache foundation three years ago (BonCode). It is a C# based AJP connector. It can currently be used with Tomcat, JBOSS, Jetty. From support requests I am surmising that is currently bundled with software from a few manufacturers including: EMC, CSC, Siemens and others instead of ISAPI redirector. Thus, I do encourage the update of the current IIS connection mechanism to a more up-to-date method. Using a managed code mechanism is the way to go in my opinion. In the long run SPDY may also be of interest for the same purpose. The more choices the better. The following are differences already in existence with BonCode and in response to your extensive writing, only read on if you are curious:: > > 1. > > The ISAPI Redirector seems to be quite complicate to configure. You have > to: > 1) place the ISAPI redirector DLL in some arbitrary path (the docs suggest > to place them in your Tomcat\bin directory) > ==> not needed > 2) create a virtual directory in your IIS web application which points to > this path > ==> not needed > 3) change the handler settings for the virtual directory to allow to > execute ISAPI dlls > ==> not needed > 4) add the ISAPI redirector DLL to the list of CGI and ISAPI restrictions > in IIS > ==> not needed > 5) add the ISAPI redirector DLL to your web app as ISAPI filter > ==> not needed > 6) create some registry entries at HKLM\Software\Apache Software > Foundation\Jakarta Isapi Redirector\1.0 to specify the path of the virtual > directory, path to configuration files etc. > ==> not needed > 7) create configuration files (uriworkersmap.properties, > worker.properties) and but them in some arbitrary path (the docs suggest to > place them in your Tomcat\conf directory) > > ==> not needed, configurations are done via the IIS UI and/or an xml config file > I see a few problems here. > First, you have to place the ISAPI redirector DLL in some external > arbitrary path. This can introduce additional maintenance issues as you > always have to remember this when e.g. moving the server. Because the docs > suggest to place them in your Tomcat\bin directory, you might delete that > file by mistake when you delete your Tomcat installation and create a new > one. > The same is true for the config files - if you place them in your Tomcat > directory, you might delete them when you change your Tomcat config. > > Normally, these files do not belong to Tomcat, but to the ISAPI > redirector, so I would expect to place them somewhere in your IIS web > application. > > E.g, ASP.Net web applications have a "web.config" file in their root > directory for configuration, and a "bin" directory where .Net assemblies > can be placed. If you were using an ASP.Net based redirector for example > (implemented as a managed module), you can place the binary into the "bin" > directory of your IIS webapp and configure it by adding it to the > web.config file. This would also mean that you don't have to create a > virtual directory any more. > > I also got problems with the system-wide registry keys that you need to > set up for the ISAPI redirector, as they don't allow separate configs for > different IIS webapps. I once tried to create a "isapi_redirect.properties" > with the configuration (instead of using the registry) like it is described > on the Tomcat Connectors IIS reference page [1], but I didn't have success, > so I reverted back to the registry settings. > > Note also that Microsoft has deprecated ISAPI filters and extensions in > favor of native http modules [2]. > > ==> not needed > > 2. > > When using the ISAPI redirector with IIS 7, I got a few problem
