You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Konstantin Preißer <ve...@t-online.de> on 2012/03/12 02:08:45 UTC
Possible alternative Tomcat IIS Connector implementation
Hello Tomcat developers,
I'm Konstantin Preißer, a german student of Computer Science. I'm developing programs with Java and .Net/C#.
Since I have been using Tomcat with IIS (JK ISAPI Connector) for quite some time now, I wondered if it may be an option for the Apache software foundation / Tomcat developers to have an alternative implementation of a IIS <-> Tomcat connector.
IIS 7.0 introduced a new module-based request pipeline, which allows to add managed (.Net) and native (C++) modules to the request processing pipeline. A managed module means that it is written in a language of the Microsoft .Net Framework (e.g. C#), which is very similar to Java. Specifically, it is a Class which implements the System.Net.IHttpModule interface, and for example can get called each time a request is made to IIS. It then has access to HttpRequest and HttpResponse objects (like a Java HttpServlet).
Since I had some free time today, I decided to try to start an implementation of a IIS-Tomcat connector by creating a managed IIS module, which would intercept requests and send them on a AJP connection to Tomcat. For this, I used the AJP protocol documentation here: http://tomcat.apache.org/connectors-doc/ajp/ajpv13a.html
I know there's already another implementation of such a module, but it is from another site/organisation and not from Apache. However, I thought it might be good if there's an official Apache implementation of such a IIS module, and I would happily give the complete source and licenses etc. to Apache, if anyone is interested.
I started with the implementation today and got now to a point where basic features (redirecting GET/POST requests (with message body) to Tomcat) seems to work well, although, of couse, a lot of features are not yet implemented (logging, configuration, error handling, ...). The code is written in C# (using the .Net Framework 4.0). If you want to take a look at it, you can download the sources from the SVN repo here: https://pleier-it.de:8543/svn/testRepo/trunk/.Net-Projekte/IIS_AJP_Module/ (note that the site uses a self-signed certificate, causing a certificate warnings in browsers). It is a Visual Studio 2010/Framework 4.0 project.
If you want to try it on IIS 7.0/7.5/8.0 Beta, you can do the following:
0. Ensure that Tomcat is running with an AJP connector on localhost:8009. Also ensure that you have the .Net Framework 4.0 (Full version) installed, and that the IIS application pool which you would like to try the connector with is using the Framework 4.0 and "Integrated" Managed Pipeline Mode. (You can also try with an earlier version, but I'm not sure if the code will compile there)
1. In your IIS site root directory (e.g. C:\inetpub\wwwroot\), create a folder with the name "App_Code", and copy all *.cs files from the source code into that directory (or a subdirectory).
2. In the IIS manager, click on the site/virtual host where you would like to test the connector, then click on item "Modules".
3. Click on "Add Managed Module...". In the combobox, type "MyModuleNamespace.IisAjpModule.AjpModule" (without quotes) and enter a name for the module in the textbox above. Make sure "Invoke only for requests to ASP.Net managed applications etc" is not selected. Then click OK, and when a Message appears that the type could not be found in referenced libraries, click Yes.
4. Open a browser and goto http://localhost/. You should now see a page served by Tomcat.
As I already said, the current code is far from being considered as "finished", but it can demonstrate the principle. (I'm also not sure how exactly the IIS request pipelining works, and if the current way how the module intercepts the request is correct, but at least it seems to work ;) ).
I think, compared to the ISAPI approach, there are some advantages and disadvantages of this connector:
Advantages:
- Easier to maintain. I have looked a bit at the ISAPI code, and as it is C++ code, it is probably somewhat hard to maintain. As I said, for this connector (in the current stage) I only spend one day to read the AJP documentation and to program the module, so it is probably very easy to write a AJP connector this way. :)
- Easier to install (you don't have to setup virtual directories etc).
Disadvantages:
-Probably worse Performance. Although I haven't done any performance tests (and when testing with a normal browser, I didn't notice any performance slowdown), such a managed connector probably has a bit worse performance compared to the ISAPI connector. (However, the current implementation also doesn't use an AJP Connection pool; and you would need to precompile the C# code to a .dll file for optimal performance).
Please let me know what you think about it. I won't be disappointed if you aren't interested in it or if there's no requirement for such a connector, but I'm happy for any feedback, and I would also be willing to give the code, licences etc. to the Apache software foundation, if that's possible.
Thank you very much for reading this (and replying)!
Regards,
Konstantin Preißer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
RE: Possible alternative Tomcat IIS Connector implementation
Posted by Konstantin Preißer <ve...@t-online.de>.
Hello Mladen,
> -----Original Message-----
> From: Mladen Turk [mailto:mturk@apache.org]
> Sent: Monday, March 12, 2012 8:00 PM
> To: dev@tomcat.apache.org
> Subject: Re: Possible alternative Tomcat IIS Connector implementation
>
> You would need to read at least one frame.
> Suppose a thread that would drain the frame would be needed
> in case client closes the connection prematurely.
>
Sorry, I think I didn't fully understand you here, but probably I didn't express myself well.
Actually I meant to talk about flow control in SPDY per stream - but I see now that I read an old draft of the SPDY protocol where this wasn't mentioned. The current draft 3 (http://mbelshe.github.com/SPDY-Specification/draft-mbelshe-spdy-00.xml) talks about flow control in SPDY streams (e.g. section 2.6.8 "WINDOW_UPDATE"), so there shouldn't be a problem with this when implementing server-to-server communication. So maybe I can try to start an IIS SPDY connector. :)
Thanks,
Konstantin Preißer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Possible alternative Tomcat IIS Connector implementation
Posted by Mladen Turk <mt...@apache.org>.
On 03/12/2012 07:51 PM, Konstantin Preißer wrote:
>
> Now imagine that a Client with a very slow connection requests a file from Tomcat which is very big. IIS would create a SPDY stream over an existing TCP connection to start retrieving the file. However, When the stream is established and Tomcat begins to send the file, IIS would not be able to send all the chunks which it gets from the SPDY connection to the client immediately, since there is a very slow connection to the client. However, IIS can't simply stop reading from the SPDY connection
You would need to read at least one frame.
Suppose a thread that would drain the frame would be needed
in case client closes the connection prematurely.
Regards
--
^TM
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
RE: Possible alternative Tomcat IIS Connector implementation
Posted by Konstantin Preißer <ve...@t-online.de>.
Hello Mladen,
> -----Original Message-----
> From: Mladen Turk [mailto:mturk@apache.org]
> Sent: Monday, March 12, 2012 8:24 AM
> To: dev@tomcat.apache.org
> Subject: Re: Possible alternative Tomcat IIS Connector implementation
>
>
> I would rather see SPDY connector over AJP.
> AJP has serious limitations, and recently we discussed using SPDY for
> server-to-server communication.
>
Thank you very much for your reply.
I had a quick look at SPDY, and you're right, SPDY has features for using a TCP connection more efficiently (e.g. to multiplex streams over a single TCP connection). Maybe when I have some time again, I should look into creating an SPDY connector for IIS to Tomcat? :)
However, currently I'm having a small doubt about a server-to-server communication with SPDY, but maybe it is only because I didn't look that much into SPDY, so please correct me if I'm saying something wrong now.
>From what I read from SPDY specification, it allows to multiplex lot of streams over a single TCP connection. E.g. when IIS would communicate to Tomcat over SPDY, a single TCP connection would allow to process multiple requests at a time.
Now imagine that a Client with a very slow connection requests a file from Tomcat which is very big. IIS would create a SPDY stream over an existing TCP connection to start retrieving the file. However, When the stream is established and Tomcat begins to send the file, IIS would not be able to send all the chunks which it gets from the SPDY connection to the client immediately, since there is a very slow connection to the client. However, IIS can't simply stop reading from the SPDY connection, because there may be frames which belongs to other SPDY streams (e.g. other clients). This would mean that IIS needs to continue reading and cache the output from Tomcat somewhere, until the connected client reads it. Is this correct? (E.g. imagine a servlet creates dynamically 1 GB of data, which IIS would need to cache somewhere in order to be able to get chunks from other SPDY streams. Whereas with AJP, IIS would simply stop reading from the AJP connection which doesn't affect other clients.) Wouldn't this be a problem? (But probably I'm just missing something which allows to control this behavior).
Thank you!
Regards,
Konstantin Preißer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Possible alternative Tomcat IIS Connector implementation
Posted by Mladen Turk <mt...@apache.org>.
On 03/12/2012 02:08 AM, Konstantin Preißer wrote:
> Hello Tomcat developers,
>
>
> Advantages:
> - Easier to maintain. I have looked a bit at the ISAPI code, and as it is C++ code, it is probably somewhat hard to maintain. As I said, for this connector (in the current stage) I only spend one day to read the AJP documentation and to program the module, so it is probably very easy to write a AJP connector this way. :)
> - Easier to install (you don't have to setup virtual directories etc).
>
I would rather see SPDY connector over AJP.
AJP has serious limitations, and recently we discussed using SPDY for
server-to-server communication.
> Disadvantages:
> -Probably worse Performance. Although I haven't done any performance tests (and when testing with a normal browser, I didn't notice any performance slowdown), such a managed connector probably has a bit worse performance compared to the ISAPI connector. (However, the current implementation also doesn't use an AJP Connection pool; and you would need to precompile the C# code to a .dll file for optimal performance).
>
Well, you have a very optimistic list here ;)
Think that the performance is of least concern.
>
> Please let me know what you think about it. I won't be disappointed if you aren't interested in it or if there's no requirement for such a connector, but I'm happy for any feedback, and I would also be willing to give the code, licences etc. to the Apache software foundation, if that's possible.
>
Like said. Not sure if the AJP protocol is the right direction.
The current connector does the job and exploits the AJP protocol to its
maximum and I see no purpose for another AJP connector.
Sure install might be simpler, but only if you don't
count differences in .NET each IIS requires so hardly binary portable like
isapi_redirector which can basically run on any IIS for XP up.
Regards
--
^TM
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
RE: Possible alternative Tomcat IIS Connector implementation
Posted by Konstantin Preißer <ve...@t-online.de>.
Hello Jordan,
> -----Original Message-----
> From: Jordan Michaels [mailto:jordan@viviotech.net]
> Sent: Monday, March 12, 2012 8:15 PM
> To: Tomcat Developers List
> Subject: Re: Possible alternative Tomcat IIS Connector implementation
>
> Hi Konstantin,
>
> If you're interested in a IIS->Tomcat connector in .NET, there's
> already
> one that exists over here:
>
> http://tomcatiis.riaforge.org/
>
> It's licensed under the Apache license, and works well. I am not a .NET
> developer, so I haven't looked at the code myself, but I have worked
> with Bilal (the author) on several projects; he's sharp, accommodating,
> and even speaks German I believe. I'd encourage you guys to coordinate
> since you obviously have similar interests.
>
> Perhaps you all could implement SPDY?
>
> Warm Regards,
> Jordan Michaels
>
Thanks. Yes, that project was what I meant with "another implementation", but I wanted to try it a bit myself :)
However, I think I will not continue my IIS-AJP connector as the connector which you mentioned is already finished and works well, and as Mladen pointed me to SPDY, so I think I will try that instead. I agree that it might be a good idea to collaborate on such a project. :)
Regards,
Konstantin Preißer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Possible alternative Tomcat IIS Connector implementation
Posted by Jordan Michaels <jo...@viviotech.net>.
Hi Konstantin,
If you're interested in a IIS->Tomcat connector in .NET, there's already
one that exists over here:
http://tomcatiis.riaforge.org/
It's licensed under the Apache license, and works well. I am not a .NET
developer, so I haven't looked at the code myself, but I have worked
with Bilal (the author) on several projects; he's sharp, accommodating,
and even speaks German I believe. I'd encourage you guys to coordinate
since you obviously have similar interests.
Perhaps you all could implement SPDY?
Warm Regards,
Jordan Michaels
On 03/11/2012 06:08 PM, Konstantin Preißer wrote:
> Hello Tomcat developers,
>
> I'm Konstantin Preißer, a german student of Computer Science. I'm developing programs with Java and .Net/C#.
>
> Since I have been using Tomcat with IIS (JK ISAPI Connector) for quite some time now, I wondered if it may be an option for the Apache software foundation / Tomcat developers to have an alternative implementation of a IIS<-> Tomcat connector.
>
>
> IIS 7.0 introduced a new module-based request pipeline, which allows to add managed (.Net) and native (C++) modules to the request processing pipeline. A managed module means that it is written in a language of the Microsoft .Net Framework (e.g. C#), which is very similar to Java. Specifically, it is a Class which implements the System.Net.IHttpModule interface, and for example can get called each time a request is made to IIS. It then has access to HttpRequest and HttpResponse objects (like a Java HttpServlet).
>
> Since I had some free time today, I decided to try to start an implementation of a IIS-Tomcat connector by creating a managed IIS module, which would intercept requests and send them on a AJP connection to Tomcat. For this, I used the AJP protocol documentation here: http://tomcat.apache.org/connectors-doc/ajp/ajpv13a.html
> I know there's already another implementation of such a module, but it is from another site/organisation and not from Apache. However, I thought it might be good if there's an official Apache implementation of such a IIS module, and I would happily give the complete source and licenses etc. to Apache, if anyone is interested.
>
>
> I started with the implementation today and got now to a point where basic features (redirecting GET/POST requests (with message body) to Tomcat) seems to work well, although, of couse, a lot of features are not yet implemented (logging, configuration, error handling, ...). The code is written in C# (using the .Net Framework 4.0). If you want to take a look at it, you can download the sources from the SVN repo here: https://pleier-it.de:8543/svn/testRepo/trunk/.Net-Projekte/IIS_AJP_Module/ (note that the site uses a self-signed certificate, causing a certificate warnings in browsers). It is a Visual Studio 2010/Framework 4.0 project.
>
>
> If you want to try it on IIS 7.0/7.5/8.0 Beta, you can do the following:
>
> 0. Ensure that Tomcat is running with an AJP connector on localhost:8009. Also ensure that you have the .Net Framework 4.0 (Full version) installed, and that the IIS application pool which you would like to try the connector with is using the Framework 4.0 and "Integrated" Managed Pipeline Mode. (You can also try with an earlier version, but I'm not sure if the code will compile there)
>
> 1. In your IIS site root directory (e.g. C:\inetpub\wwwroot\), create a folder with the name "App_Code", and copy all *.cs files from the source code into that directory (or a subdirectory).
>
> 2. In the IIS manager, click on the site/virtual host where you would like to test the connector, then click on item "Modules".
>
> 3. Click on "Add Managed Module...". In the combobox, type "MyModuleNamespace.IisAjpModule.AjpModule" (without quotes) and enter a name for the module in the textbox above. Make sure "Invoke only for requests to ASP.Net managed applications etc" is not selected. Then click OK, and when a Message appears that the type could not be found in referenced libraries, click Yes.
>
> 4. Open a browser and goto http://localhost/. You should now see a page served by Tomcat.
>
>
> As I already said, the current code is far from being considered as "finished", but it can demonstrate the principle. (I'm also not sure how exactly the IIS request pipelining works, and if the current way how the module intercepts the request is correct, but at least it seems to work ;) ).
>
> I think, compared to the ISAPI approach, there are some advantages and disadvantages of this connector:
>
> Advantages:
> - Easier to maintain. I have looked a bit at the ISAPI code, and as it is C++ code, it is probably somewhat hard to maintain. As I said, for this connector (in the current stage) I only spend one day to read the AJP documentation and to program the module, so it is probably very easy to write a AJP connector this way. :)
> - Easier to install (you don't have to setup virtual directories etc).
>
> Disadvantages:
> -Probably worse Performance. Although I haven't done any performance tests (and when testing with a normal browser, I didn't notice any performance slowdown), such a managed connector probably has a bit worse performance compared to the ISAPI connector. (However, the current implementation also doesn't use an AJP Connection pool; and you would need to precompile the C# code to a .dll file for optimal performance).
>
>
> Please let me know what you think about it. I won't be disappointed if you aren't interested in it or if there's no requirement for such a connector, but I'm happy for any feedback, and I would also be willing to give the code, licences etc. to the Apache software foundation, if that's possible.
>
>
> Thank you very much for reading this (and replying)!
>
>
> Regards,
> Konstantin Preißer
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org