-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Frederik,
On 9/28/15 11:13 AM, Frederik Nosi wrote: > Hi, On 09/26/2015 02:04 AM, Christopher Schultz wrote: Graham, > > On 9/25/15 7:23 PM, Graham Leggett wrote: >>>> On 25 Sep 2015, at 10:33 PM, Christopher Schultz >>>> <ch...@christopherschultz.net> wrote: >>>> >>>>> While I obviously agree with the sentiment, I do feel bad >>>>> for the OP who has to fight this battle. >>>> It is important however to clarify that this isn’t a typical >>>> scenario, lest someone cites this thread as to why they >>>> should be doing the same thing. >>>> >>>>> 1. All the code we currently have in tcnative uses APR for >>>>> everything, and I'm not sure if APR supports AF_UNIX >>>>> sockets, or even if it would have to support them to do >>>>> this. >>>> The as-yet-unreleased v1.6 of APR does support unix domain >>>> sockets, although the docs for it don’t appear to be very >>>> clear. >>>> >>>>> 2. The plumbing required to configure an AF_UNIX socket is >>>>> non-trivial, and it's currently all wired-around using >>>>> AF_INET sockets, so it's got hostname, port, etc. I suppose >>>>> we could stuff the inode's name into the hostname and >>>>> ignore the port number or something like that, but it's >>>>> fairly hacky. >>>> Currently APR seems to accept the UDS filename where the IP >>>> address would otherwise be provided. >>>> >>>>> So this is a non-trivial amount of work, here. >>>>> >>>>> Srini, is there any chance your employer would pay someone >>>>> to write this code? Patches are always welcome, and Tomcat >>>>> is otherwise completely free… >>>> If there was a push for unix domain sockets from Tomcat it >>>> would definitely help working out whether the APR_UNIX >>>> implementation does what it needs to do, and gets properly >>>> documented and v1.6 released. > I don't really see this happening. > > I'm fairly sure that the widespread use of HTTP/2 is going to kill > AJP forever, leaving only mod_proxy_http(2) as a viable long-term > connector. Nobody is ever going to bother writing an AF_UNIX > connector for HTTP/2, so I think this idea is very likely to die in > this thread. > >> Not sure on this, as AJP is quite handy. Expecialy load balancing >> java webapps and i find mod_jk quite good at this. Remember, it's not mod_jk doing the load-balancing, it's Apache httpd. mod_jk is simply providing the channel over which the proxying is being done. In a thread on the dev list, I'm a little more defensive of AJP because of its ability to pass data out-of-band with respect to the tunneled HTTP message. There definitely is utility there. >> Out of curiosity, why do you think so? What does offer HTTP/2 >> that can be handy in a reverse proxy scenario? Compression / >> streams? It's not that I think HTTP/2 offers a particular advantage over AJP, but HTTP/2 *will* be implemented and it offers a number of advantages over AJP (specifically, encryption as part of the HTTPS protocol). Currently, AJP doesn't support the connection-oriented web protocols like Websocket, and it just seems like it will be a huge effort to get AJP to be able to tunnel everything that both HTTP and HTTP/2 offer. Since HTTP/2 is going to (eventually) have to support all this, and httpd is going to (eventually) implement HTTP/2 proxying, I'm not sure I see a great benefit to continuing to maintain AJP and mod_jk along with it. mod_jk was great when proxying was otherwise very complicated with Apache httpd. That's no longer the case, and I think it makes sense to push mod_proxy_http to support all the great features that AJP/mod_jk is currently providing. There is no great need to maintain two components that do pretty much the same thing, when one of those components (mod_jk) has a very narrow use-case and the other (mod_proxy_http) has very wide applicability. - -chris -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJWCWY6AAoJEBzwKT+lPKRYVboP/3t1DbLZ3IgizG6ISeuQmDJC kxlFnxhKZ5EErI3o9BUIs/e65/iWqVNNhY6AMJOPcMKEfLDc7SsF0Vu5+Y/Si4K8 5Y+s1l1t5peLJB6eNxAGaCEULE3DwBtCF2Zwok99OdGWEzXI8NzHpCUIPdJ2Uh0g ezeaY1MAkYTzs1JGsN+m7u4Z04h6khnhS6hSseFoCKyF1nFHTb+f7xjBbT9dN2CO kBANTK+CjT/WtOw3pjb9EMJ7AbRO4AgoT2gfuuol+LDTeQZiWcwQpLXLIxKN84ra rStt1ijPGVUbar4q/DHq+gbUk4CeDQwcpVqTBeos2r+GSV2BqWiGrqdTstA6qUXl evn61o0PTOA9raNTn8PIhxWhJOuKn6gQOGvW2NQzVuqAzLTqeqep8cCsvcQkjQkj NlbjSrCJR5iiP0V/Q68cqX6qgJvZcMjQ4EFHxswKxS19xg4NhHU3wW1CuhzShZxa DUfxVDTT1Jnk36CaX2ijIY/q7oxQMDfuuLub4Tmg974o4HcPuNG/c0Y72A7yZbaZ mxwfxezGGu9QAwyVzAg1EF7QOaCgO1tvIjfimuG6ye27bJeX6WTT6FDvdHFYsCjk H6e/j5qv3OLff217Y73g+LLiDlbqO+RbowBSzGNBTZtnMKaxrqG0tYObfJmk5stY mIYPp6B/CrsY3fSlPDna =QplG -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
