I strongly suspect your problem is related to AJP.
I was in a course with one of the main Tomcat developers a few weeks ago (he was running it), his advice was to avoid AJP and mod-JK etc, and stick to regular mod-proxy HTTP.
Reasons:
- It's by far the most mature and stable Tomcat connector.
- Neither AJP implementation has been consistently developed; both projects have suffered a bit of stop / start.
- NBIO does not result in any real world performance gain over blocking-IO, in this situation.
My advice, try using regular mod-proxy HTTP with your current setup. It's the least change for you and it will take you on to the most widely used and stable Tomcat deployment architecture.
/ Richy
Alias /students /var/www/students
<Location /students>
KrbServiceName HTTP
KrbMethodNegotiate On
KrbMethodK5Passwd On
KrbSaveCredentials off
KrbAuthRealms DOMAIN.LOCAL
Krb5KeyTab /etc/httpd/keytab
KrbAuthoritative off
AuthType Kerberos
AuthName "Please Login"
AuthBasicProvider ldap
AuthzLDAPAuthoritative on
AuthLDAPURL "ldap://dc.domain.local:389/OU=Domain Users,DC=domain,DC=local?userPrincipalName?sub?(objectClass=*)"
AuthLDAPBindDN "CN=ldapsearchuser,CN=Users,DC=domain,DC=local"
AuthLDAPBindPassword ldapsearchuserpass
require ldap-group CN=Students,CN=Users,DC=domain,DC=local
require ldap-group CN=Staff,CN=Users,DC=domain,DC=local
</Location>
This allows all users who are members of either the Students/Staff AD groups access to pages behind http://intranetsite/students without needing to specify login credentials provided their IE/Firefox are configured properly.
The userPrincipalName was used instead of sAMAccountName because the kerberos module was passing the username@REALM to the ldap module.
Now I have the problem where if someone isn't authorized they are presented with:
Authorization Required
This server could not verify that you are authorized to access the document requested. Either you supplied the wrong credentials (e.g., bad password), or your browser doesn't understand how to supply the credentials required.
Does anyone know how to have it pop up a username/password dialog box so they could try alternate credentials? After unsuccessfully gaining authorization, the only way I can get it to ask for credentials is to clear out my cache. If I am logged in to the PC as an authenticated user but one that isn't authorized to this resource I have no way of suppying alternate credentials (which may be a good thing).
Best Answer
All the comet solutions rely on holding the connection between the webserver open as long as possible, either by the client making a
POST
request and then delaying sending the data, or the server sending aGET
response, again delaying the data.Both of those have similar problems for the origin, namely consuming a socket and memory per connection, and possibly a thread, unless you are using something like Jetty continuations.
By placing a reverse proxy like Apache in front of Jetty, like apache each open connection between Jetty and the client will also consume a worker. Depending on which apache worker model you choose (for example
mod_prefork
ormod_worker_mpm
) there will be limitations on the maximum number of connections your apache server can support. That is around a couple of hundred formod_prefork
and is generally limited by the amount of physical memory each worker process consumes, to a few thousand withmod_worker_mpm
. If you are mixingmod_worker_mpm
with php you should research the options that your version of php was compiled with as there are known incompatibilities with php andmod_worker_mpm
.You will also have to be mindful of the timeouts in both Apache and Jetty. Comet style connections either simulate a slow
POST
request, so you'll have to tune Apache to be lenient towards that, as well as the size of the request body.GET
style requests are also subject to timeout if nothing is transmitted from the origin server. You'll have to apply these timeouts on both sides of the reverse proxy connection, from the client to Apache, and from Apache to Jetty.If I was deploying a solution like this I would either place the Jetty based Comet service on a different domain, using a load balancer to proxy multiple Jetty backends for added capacity and reliability, or I would use a different reverse proxy, say HAProxy, to act in Apaches stead, and direct requests to the various backends (Apache, Jetty), based on the URL.