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-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
