Nick Williams wrote:
Thanks for the insight. I'll give it a little more time, but I'm being
pushed by my superiors here for an answer that I can't give, so I'll have
to file a bug before long.

Does anyone know if there are any other (open source OR commercial/paid)
alternatives to integrating Tomcat with IIS and/or Apache?

Yes, there are other possibilities for both IIS and Apache (see below).
But before you look at that, you may want to investigate your particular issue 
a bit further.

Both mod_jk (for Apache) and isapi_redirector (for IIS) are and have been used by *lots* of people for several years. This is not to say that there cannot be a bug in them, but that at least they are generally pretty reliable and have stood a lot of testing and usage in production. So before you switch to something else, you'd have to ask yourself how well-tested these alternatives are. And as far as I know, most of them are "younger" than mod_jk and isapi_redirector.

The second part is that from your description, the problem you mentioned has some characteristics which make me a bit doubtful that the issue /originated/ with isapi_redirector. Namely, as I understand your description :
1) it happened only once
2) the same configuration has been working without showing such a problem for at least one year
3) neither IIS nor Tomcat nor isapi_redirector were recently updated
4) the usage pattern for the website did not change significantly in a way that could explain a problem
5) there was no external network or system issue which could explain the problem
6) the IIS logs do not show the problem to be at the IIS level, and the Tomcat logs do not show the problem to be at the Tomcat level

Now, as the old joke goes, pick any 5 of the 6 above; because in the way my mind works, not all 6 can be true at the same time.

About the alternatives :

Both isapi_redirector and mod_jk use the AJP protocol, and the AJP connector at the Tomcat level, to handle the connection between the front-end webserver and the back-end Tomcat. Both isapi_redirector and mod_jk, in addition to being just a "proxying" solution, incorporate a load-balancing aspect, and a failover aspect.
Also both are open-source and free.

Most other solutions below use the HTTP protocol and the HTTP connector at the Tomcat level. Some of them are open-source and free, others not. Some of them offer load-balancing and/or failover, others not. isapi_redirector and mod_jk offer a lot of tuning capabilities; as far as I know, the other solutions below offer a lot less such capabilities. Whether that is an advantage or an inconvenient is in the eyes of the beholder.

1) IIS 7.0 has a built-in HTTP proxy capability. There is some configuration needed for that at the IIS level, but I do not remember the details. As far as i remember, this does not offer load-balancing or failover.
2) There are several IIS add-on modules available (not free nor open-source) 
which provide
such HTTP proxying capabilities for IIS. One of them is "isapi rewrite 3" (http://www.helicontech.com/isapi_rewrite/). 3) For Apache, you can use the mod_proxy module with the mod_proxy_http sub-module, to proxy requests from Apache to Tomcat via HTTP. This is open-source and free, and may provide for load-balancing and maybe also failover, I don't remember. 4) For Apache, you can also use mod_proxy with the mod_proxy_ajp sub-module. This still uses an AJP connection and the Tomcat AJP connector, and includes load-balancing and failover as I recall. mod_proxy_ajp, compared to mod_jk, is a relative "new kid on the block", and I really do not know how they compare in terms of performance or reliability.

My own experience is mainly with the Apache/mod_jk/Tomcat configuration, and I have never had serious problems with it. I run several servers, but none of them has the kind of load which you indicate for yours (100+ requests/second). I have occasionally used 1, 2 and 3 above, so I know that they basically work; but also not in very demanding circumstances. I have never used (4) above.




---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to