tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <>
Subject Re: SPDY support
Date Wed, 15 Feb 2012 16:11:15 GMT
On Wed, Feb 15, 2012 at 12:34 AM, Mark Thomas <> wrote:

> > Processor is tied to one request/response - Spdy protocol is a
> multiplexing
> > protocol, so one spdy connection will have 100s of Requests.
> > I am using Processor interface for each muxed spdy stream.
> Hmm. I wonder if we need a different name than Processor just to clarify
> the difference? But that is more a cosmetic issue.

It's probably too big change. Maybe some more javadocs ( I added a few
where I had to figure things out ) :-)

> > Plus - both are quite rich objects. I think it's worth using a smaller
> > interface
> > ( i.e. Endpoint.Handler with few extra extensions).
> I'd be prepared to trade a little bit of extra baggage (as I have with
> much of the connector refactoring) to increase commonality between
> components and reduce code duplication. What that means for SPDY I don't
> know yet. Again, I need to look at your latest proposal. This is more a
> general statement of the compromises I am happy making for easier
> maintenance.

I agree in general. What I'm trying to do with spdy is keep the spdy
package mostly dependence-free, with the tomcat specific code well

After I submit, I'll give a try to changing SocketWrapper (non-generic,
add read/write), in the git. If you don't like it - easy to drop the branch,
but I think it'll simplify the old connectors enough to compensate for the
extra complexity I'm adding :-)

> >>> Also: the current upgrade is quite heavy, it holds Requet/Response and
> a
> >>> bunch of
> >>> buffers.
> >>
> >> No it doesn't. Take another look at the code. The original
> >> implementation did but as I stated at the time my intention was to do
> >> some further refactoring to fix that. That refactoring has been complete
> >> (and is what resulted in the API changes I was referring to previously).
> >
> > Yes, much better now ! ( but still I don't think it's the best fit ).
> Thanks. Suggestions for improvements welcome.

Well, UpgradeProtocol has read/write methods, I would drop the streams
( keep them as separate util classes if someone wants them).
I would also drop the methods reading/writing a single byte, use only

I think most improvements I can think of involve removing code :-)
 > For non-SSL ( JIO, and apr without ssl ) -> SPDY just kicks in on all

> > connections,
> Ah. Light dawns. Do you see a requirement for non-SSL connections to be
> able to use HTTP or SPDY in the same way SSL ones can? For the proxy use
> case, an assumption of all SPDY seems valid.

Yes, there is a special header that needs to be set ( if tomcat SPDY is
working ),
browsers will stop sending http and switch to spdy  ( they'll also remember
next time ).


> > this is just a short-cut for testing. I could also define a SpdyProtocol
> > and set it
> > directly on the connector - but seems too much overhead for something
> that
> > is testing/experimental.
> Cheers,
> Mark
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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