tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Knoblauch <>
Subject Re: Plans for AJP
Date Thu, 05 Jul 2018 15:40:03 GMT
Hi Rainer,

 chiming in late... SSL support on the connector between loadbalancer and
Tomcat is something that is requested from time to time. Usually from
over-conscious security types.

We are using mod_jk today, because of:

1) we always used it. It works
2) it supports stickiness
3) the "jkmanager" interface
4) recently we started using JK_STICKY_IGNORE together with "mod_rewrite"
to remove some balancing artifacts caused by clients remembering the
session cookie

When being forced to move to another connector (e.g.
mod_proxy_http+mod_proxy_balancer), I would be most upset if there were no
alternative to "jkmanager". We use it a lot to manage the restart of worker

But then, given the proposed schedule, I will likely be retired before our
software is moving to Tomcat-9 :-)


On Wed, Jun 27, 2018 at 6:50 PM, Rainer Jung <>

> Hi there,
> BZ56402 is an AJP feature request and Remy postet
> "IMO, with each day that passes, this enhancement becomes more unrealistic
> and
> less useful. I think the decision must now be made to either start it
> immediately (with a volunteer  ) or pass on it and freeze AJP for good."
> and Chris postet:
> "It might be time to let AJP die."
> Maybe a dev list discussion about plans for AJP should happen. I heard
> several people interested in getting TLS support for mod_jk. Whenever I was
> thinking about it, I refrained from starting to work on it, because
> - good TLS support is a lot of work and I'm not sure how good mod_jk could
> reuse mod_ssl like mod_proxy does. mod_jk uses common source code for IIS
> and Apache httpd with only a thin wrapper for the individual web servers.
> Therefore it is not easy to integrate the details of comunication, which
> happens in the common source code part, with mod_ssl.
> - even if it would be done with lots of efforts, it would probably take
> quite some time to become robust and I think there's not enough interest
> and available work time to support that new and complex code for a longer
> time.
> Since encryption would be most of the most useful features and IMHO we
> won't get there, I suggest we discuss deprecation and EOL dates for AJP -
> meaning mod_jk and AJP connectors.
> There's no need to rush, but there could be a clear statement, that no
> feature improvements will be done and users should plan for moving to
> mod_proxy_http (or other http/https) clients.
> I think it would be better to invest time in improving mod_proxy where it
> still might lack. For instance adding custom headers to transport
> communication info from the proxy to the backend like AJP does and which
> could be noticed by our Tomcat http connectors and/or support for the PROXY
> protocol.
> So what do people think about:
> 1) adding a statement to the mod_jk docs, that we don't plan any feature
> enhancements and suggest users to migrate to mod_proxy_http and the TC HTTP
> connectors (but what about IIS? I think there are reverse proxy modules
> there as well?)
> 2) Adding a similar statement to the connector docs for AJP to TC 7-9.
> 3) Deprecating AJP in TC 9 and removing in TC 10
> Regards,
> Rainer
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Martin Knoblauch
email: k n o b i AT knobisoft DOT de

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message