tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Need help understanding support for Unix Domain Sockets in Tomcat 7.0.x
Date Mon, 28 Sep 2015 16:09:30 GMT
Hash: SHA256


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 
>>>> <> 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
Comment: GPGTools -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message