You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Mark Thomas <ma...@apache.org> on 2014/11/10 17:42:56 UTC
Connector refactoring
Hi,
I am about to push the first batch of commits. I started with the
upgrade package as that looked like the simplest to tackle first. Rather
than a single commit, I'll keep the individual commits from git. They
aren't all as clean as I would like but it gives a better idea of how I
approached it and (I think) is easier to review.
The unit tests all pass for all three connectors on OSX.
My thinking moving forward is to do AJP next and HTTP last. At some
point I may move the SocketWrappers to separate classes as they are
fairly large.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Connector refactoring
Posted by Rémy Maucherat <re...@apache.org>.
2014-11-10 18:32 GMT+01:00 Mark Thomas <ma...@apache.org>:
> > For example, with the NIO2 connector, the code is rather different
> between
> > upgrade and non upgrade, plus it has the possibility of doing gather
> writes
> > (not done in upgrade, only in regular mode; basically in upgrade mode the
> > framework in place was inflexible, so I didn't use gather for the NIO2
> > connector). So if the idea is to merge everything in a single read/write
> > method in the wrapper, then it's not a good idea. Ultimately being able
> to
> > do splitter/gather in upgrade mode should be good (if needed).
>
> My focus is on refactoring what we have without changing behaviour
> unless it is to add features that only some connectors have (e.g.
> non-blocking read of HTTP headers to APR/native).
>
> The current HTTP implementations are more diverse and I'm expecting that
> refactoring to be more complex. Keeping support for gather writes would
> be part of that.
>
Maybe I did sound too negative. The refactoring sounds good. But indeed
HTTP looks a lot more complex (not sure it is really mandatory since I
suppose the HTTP/1.1 IO support required will not change moving forward),
so I was worried about it, plus the possibility to add some features like
scatter/gather eventually since NIO2 supports it.
>
> >> My thinking moving forward is to do AJP next and HTTP last. At some
> >> point I may move the SocketWrappers to separate classes as they are
> >> fairly large.
> >>
> > AJP ? I don't see it working any better than the java.io connector for
> > the new technologies, so the plan should probably be to remove it or have
> > it limited to legacy mode.
>
> I'm hopeful that AJP will be extended to support HTTP upgrade. In theory
> it could also be extended to better support non-blocking IO (I'm
> thinking with httpd's event MPM).
>
> For now, I see merit in keeping in. Looking to the future it may well be
> dropped in favour of HTTP 1.1 or 2.0 proxies.
>
> I had the impression HTTP/1.1 proxies have been better for a few years now.
Rémy
Re: Connector refactoring
Posted by Mark Thomas <ma...@apache.org>.
On 10/11/2014 17:14, Rémy Maucherat wrote:
> 2014-11-10 17:42 GMT+01:00 Mark Thomas <ma...@apache.org>:
>
>> Hi,
>>
>> I am about to push the first batch of commits. I started with the
>> upgrade package as that looked like the simplest to tackle first. Rather
>> than a single commit, I'll keep the individual commits from git. They
>> aren't all as clean as I would like but it gives a better idea of how I
>> approached it and (I think) is easier to review.
>>
>> The unit tests all pass for all three connectors on OSX.
>>
>
> Ok, nice. But I'm a bit cautions, since some flexibility is lost.
OK.
> For example, with the NIO2 connector, the code is rather different between
> upgrade and non upgrade, plus it has the possibility of doing gather writes
> (not done in upgrade, only in regular mode; basically in upgrade mode the
> framework in place was inflexible, so I didn't use gather for the NIO2
> connector). So if the idea is to merge everything in a single read/write
> method in the wrapper, then it's not a good idea. Ultimately being able to
> do splitter/gather in upgrade mode should be good (if needed).
My focus is on refactoring what we have without changing behaviour
unless it is to add features that only some connectors have (e.g.
non-blocking read of HTTP headers to APR/native).
The current HTTP implementations are more diverse and I'm expecting that
refactoring to be more complex. Keeping support for gather writes would
be part of that.
>> My thinking moving forward is to do AJP next and HTTP last. At some
>> point I may move the SocketWrappers to separate classes as they are
>> fairly large.
>>
> AJP ? I don't see it working any better than the java.io connector for
> the new technologies, so the plan should probably be to remove it or have
> it limited to legacy mode.
I'm hopeful that AJP will be extended to support HTTP upgrade. In theory
it could also be extended to better support non-blocking IO (I'm
thinking with httpd's event MPM).
For now, I see merit in keeping in. Looking to the future it may well be
dropped in favour of HTTP 1.1 or 2.0 proxies.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Connector refactoring
Posted by Rémy Maucherat <re...@apache.org>.
2014-11-10 17:42 GMT+01:00 Mark Thomas <ma...@apache.org>:
> Hi,
>
> I am about to push the first batch of commits. I started with the
> upgrade package as that looked like the simplest to tackle first. Rather
> than a single commit, I'll keep the individual commits from git. They
> aren't all as clean as I would like but it gives a better idea of how I
> approached it and (I think) is easier to review.
>
> The unit tests all pass for all three connectors on OSX.
>
Ok, nice. But I'm a bit cautions, since some flexibility is lost.
For example, with the NIO2 connector, the code is rather different between
upgrade and non upgrade, plus it has the possibility of doing gather writes
(not done in upgrade, only in regular mode; basically in upgrade mode the
framework in place was inflexible, so I didn't use gather for the NIO2
connector). So if the idea is to merge everything in a single read/write
method in the wrapper, then it's not a good idea. Ultimately being able to
do splitter/gather in upgrade mode should be good (if needed).
>
> My thinking moving forward is to do AJP next and HTTP last. At some
> point I may move the SocketWrappers to separate classes as they are
> fairly large.
>
> AJP ? I don't see it working any better than the java.io connector for
the new technologies, so the plan should probably be to remove it or have
it limited to legacy mode.
Rémy