Re: Plans for AJP

[Martin Knoblauch <kn...@knobisoft.de>]

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
Tomcats.

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

Thanks
Martin


On Wed, Jun 27, 2018 at 6:50 PM, Rainer Jung <ra...@kippdata.de>
wrote:

> 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: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>


-- 
------------------------------------------------------
Martin Knoblauch
email: k n o b i AT knobisoft DOT de
www: http://www.knobisoft.de

Re: Plans for AJP

[Rainer Jung <ra...@kippdata.de>]

Hi Martin,

Am 05.07.2018 um 17:40 schrieb Martin Knoblauch:
> 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
> Tomcats.
> 
> But then, given the proposed schedule, I will likely be retired before our
> software is moving to Tomcat-9 :-)

thanks for your feedback and past contributions to mod_jk.

Maybe you find some time to look at mod_proxy_http, mod_proxy_balancer 
and its balancer manager GUI. Some tings are better there, some things 
not as good. It would be interesting to get feedback over time, what is 
missing most in the mod_proxy world. We might be able to help getting 
things improved there.

Thanks and regards,

Rainer

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org