tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <>
Subject Re: jk/cluster - intelligent systems load
Date Tue, 16 Feb 2010 17:57:58 GMT
On Tue, Feb 16, 2010 at 1:38 AM, Mladen Turk <> wrote:

> On 02/16/2010 10:21 AM, Mark Thomas wrote:
>> On 16/02/2010 09:08, Mladen Turk wrote:
>>> On 02/16/2010 09:56 AM, Mark Thomas wrote:
>>>> The other thing it potentially allows is the cluster to tell the proxy
>>>> about which nodes are in the cluster, allowing a more dynamic
>>>> configuration. Not sure I'd want to use that in production, but in dev
>>>> that could be useful.
>>> Hmm, the zero conf is actually more desired in production then in
>>> dev environments since it allows single point of admin and no need
>>> for webserver reconfig.
>> Its just a personal opinion. I don't like any form of auto-configuration
>> in production because I always feel I never quite know what it is doing
>> or, more importantly, what it might do.
> Well it's zero conf inside web server only, so its conf is passed from
> Tomcat, and that is certainly something strictly defined inside .xml or
> via some manager app.
> There was attempt for creating AJP14 protocol, since the current one
> lacks some IPC capabilities with the limited packed size being the major
> problem. However I'd rather see mod_jk/isapi with http protocol then
> creating
> some AJP extensions or even completely new protocol. Network and processing
> speed changed a lot since 90's so now there's almost no performance
> difference
> between AJP and HTTP implementations. With some new HTTP proposals for
> connection reusing even that factor could be eliminated in the future.
IMHO bi-directional communication is quite important - there are all kind of
protocols ( web socket, SPDY ) that requires it. You can have apache as a
for those protocols - but than you need AJP or mod_proxy to support it as

I think the main driver for replacing ajp is the 2-directional protocols -
and if we
replace it, why invent a new protocol and not just adopt SPDY, which has all
we need.

There are some issues with SPDY - like the requirement to compress and do
but we can easily tweak it.

Regarding auto-conf , smarter load balancing and the other features enabled
by 2-directional
communication - in a large enough cluster they become quite important.


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