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 Wed, 17 Feb 2010 18:37:54 GMT
On Wed, Feb 17, 2010 at 12:38 AM, Mladen Turk <> wrote:

> On 02/16/2010 06:57 PM, Costin Manolache wrote:
>> 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.
> Totally agree.
> Both JK and AJP originate from days when the single server behind
> web server was the common topology and when there was no async processing.
> Beside SPDY, which some ASF folks that made a significant contribution
> to the original HTTP specs consider as unperfect, there is BWTP proposal
> (
SPDY has quite a few problems - but it's still an improvement over AJP and
2-directional and mulitplexing to HTTP - which is what we need. The main
problem with a protocol is getting enough critical mass to overcome it's
problems -
HTTP is not perfect either.

The reasons I suggest using SPDY as a replacement for AJP - and supporting
out-of-box in tomcat:
- it does what we need
- there is one browser supporting it - and likely to take advantage of it
- probably there will be at least one large domain using it :-)
- There is also a mod_spdy for apache, and I'm sure there will be more.

Regarding problems, my list is not very big:

- requirements for compression and SSL - we don't need this for
apache-tomcat communication.
But it's easy to extend or configure the protocol to skip it / negotiate.

- right now they only want to do it over 443 ( i.e. use CONNECT method ) to
make sure proxies won't
get in the way. Apparently UPDATE doesn't work in some places. That's also
something we can
extend - and seems to be due more to the desire to get something deployed.

- of course - the current next-protocol SSL extension is out of question for
java - which has problems
even with the SSL session ticket. We might be able to support it with

- some cosmetic issues - I would prefer protobufs or thrift instead of
yet-another binary format,
sending the url as a header seems strange, binary header could be smaller,
the server push is also
a bit more complex than it should be. I don't think any matters, working
around http is much worse.

- I'm waiting for the flow control to be finalized - but seems reasonable.

> Extending exiting protocols or just doing a 'quick hacks' like I
> see with many projects trying to address those issues will not
> work in the long run. At the end you will be faced with the
> clean drawing board.

There is never a 'clean drawing board', or a perfect protocol. Any new
protocol needs
to be adopted and needs to deal with existing infrastructure - proxies,
blocked ports,
timeouts in NATs, etc.

BWTP doesn't seem so much better - mostly cosmetics. It's also more focused
as a
websocket - not as a browser-proxy-server protocol. And the list of
implementations and
potential adoption matters a lot for protocols.

( BTW: I write this wearing my own hat, my work on tomcat-lite and spdy is
on my own time, etc )


> Regards
> --
> ^TM
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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