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 <cos...@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.koli...@gmail.com >> >> wrote: >> > >> >> 2012/2/22 Costin Manolache <cos...@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 >
