tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: Need help understanding support for Unix Domain Sockets in Tomcat 7.0.x
Date Mon, 28 Sep 2015 16:09:30 GMT
-----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 
>>>> <chris@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message