Re: SPDY support

[Costin Manolache <co...@gmail.com>]

Submitted the second part - please let me know if there are concerns with
the layout/etc.

Note that Jetty announced spdy support as well, and they're using a NPN
implementation that requires Java7. Their NPN library seems to have ASF
licence ( dual eclipse/asf ), I'll try to get it working with the NIO
connector - not sure if it's ok to add this dependency, but at least to
compare them.

( NPN == "next protocol negotiation", a TLS extension required for SPDY
support )

Costin

On Wed, Feb 22, 2012 at 11:08 PM, Costin Manolache <co...@gmail.com> wrote:

> On Wed, Feb 22, 2012 at 10:47 AM, Mark Thomas <ma...@apache.org> wrote:
>
>> On 22/02/2012 18:41, Costin Manolache wrote:
>> > On Wed, Feb 22, 2012 at 10:27 AM, Konstantin Kolinko <
>> knst.kolinko@gmail.com
>> >> wrote:
>> >
>> >> 2012/2/22 Costin Manolache <co...@gmail.com>:
>> >>> On Wed, Feb 22, 2012 at 8:57 AM, Mark Thomas <ma...@apache.org>
>> wrote:
>> >>>
>> >>>> On 22/02/2012 16:51, Costin Manolache wrote:
>> >>>>> First part submitted. For the second: what is the process for
>> adding a
>> >>>>> dependency ?
>> >>>>
>> >>>> Why do you need the dependency?
>> >>>>
>> >>>
>> >>> Spdy requires header compression - with a pre-defined dictionary (
>> >>> containing header names and common values ). It also requires 'flush'
>> - a
>> >>> single compression context is used for all headers in the stream.
>> AFAIK
>> >>> this is not possible with the jdk compress library.
>> >>>
>> >>> That's one of the ways spdy gets its speed - it is not optional in
>> >>> chrome/firefox.
>> >>>
>> >>
>> >> 1. AJP/1.3 protocol has dictionary for header names.
>> >> 2. In Deflater class explicit flush operation was added in Java 1.7.
>> >>
>> >
>> > I think requiring Java1.7 is too much. Most prod servers are on 1.6.
>> >
>> > Would making it an 'optional' dependency work ( i.e. skip compiling the
>> > required
>> > classes / use class for name ) ? I can add an option to use 1.7
>> Deflater if
>> > available.
>>
>> If we are talking about Tomcat 8 then that is very likely to require
>> Java 1.7 anyway. 1.6 is close to EOL.
>>
>> Are you considering back-porting this to 7.0.x?
>>
>> There is also a workaround already in 7.0.x for flushing compressed
>> streams.
>>
>
> Cool, that's something I didn't expect... Whoever found this workaround -
> I owe you a beer.
>
> I will try to compare the perf and mem use of the 2 for my curiosity - but
> for now I'm using the java deflater.
>
> I still have to submit the tests and some client code, but with the last
> commit ( assuming I didn't break something ), with the right version of
> tcnative and openssl it should work.
>
> What's the test env. for the automated tests ? Are APR tests run - and
> with what library ?
>
> Costin
>