tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: JK Connector failure after IIS recycle - version 1.2.30
Date Thu, 26 May 2011 08:19:07 GMT
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

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" 
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:
For additional commands, e-mail:

View raw message