On Thu, Mar 15, 2012 at 7:10 AM, Filip Hanik - Dev Lists <devli...@hanik.com > wrote:
> On 3/15/2012 6:54 AM, Mark Thomas wrote: > >> On 14/03/2012 17:42, Filip Hanik Mailing Lists wrote: >> >>> http://people.apache.org/~**fhanik/reports/servers/<http://people.apache.org/~fhanik/reports/servers/> >>> >>> Attached is a patch that leverages the Tomcat WebSocket API with >>> minimalistic changes and uses that to implement WebSockets in Tomcat >>> 6.0.x >>> http://people.apache.org/~**fhanik/websockets-for-tomcat-**6.patch<http://people.apache.org/~fhanik/websockets-for-tomcat-6.patch> >>> >> Nice. There was me hoping the WebSocket support would be a driver for >> upgrading to 7.0.x. Oh well. Having the the support in 6.0.x is very nice. >> >> This implementation doesn't touch the endpoints or any real connector >>> logic, making it risk free. The only change that could do anything, >>> would be the XXXProcessor + if (statusCode == >>> HttpServletResponse.SC_**SWITCHING_PROTOCOLS) { + >>> outputBuffer.addActiveFilter + >>> (outputFilters[Constants.**IDENTITY_FILTER]); + } else >>> >> Those look OK to me. I do wonder if the changes to >> CometEventImpl#setTimeout() might cause a surprise for someone though. >> > yes it could, but I doubt it. I felt it was very important to not change > the API for a . release of Tomcat 6 this late in the game. > Instead of calling I can do > > ((Request)getField("request", event)).protocolSwitch(); > and now that you mention it, I will change the patch to do just that. It > is much clearer. > > > > >> Where it sets an identity filter when the user is switching >>> protocols. Otherwise Tomcat defaults to chunked encoding. You can >>> still see Tomcat 8 sends a Transfer-Encoding:chunked as part of a web >>> socket response. >>> >> That should probably be cleaned up although it doesn't matter that much >> since no response body is sent back anyway. >> >> This implementation also works with BIO connector, as Tomcat's >>> CometProcessor interface supports both, and let's the implementer >>> implement both Comet and non Comet in the same class. >>> >>> Hopefully this patch shows 1. It's fairly risk free to implement this >>> in stables branches as Tomcat 6, and possibly Tomcat 7 (as we may >>> want to treat this as fairly stable and minimize refactoring this >>> late in the game) 2. Performance of Comet is similar to the non Comet >>> implementation 3. It took me 4 hours to do this migration, so it's >>> definitely very easy to work with Comet once you have the bulk work >>> done (the WebSocket protocol impl by Mark Thomas) >>> >>> The test suite report is at >>> http://people.apache.org/~**fhanik/reports/servers/<http://people.apache.org/~fhanik/reports/servers/> >>> >>> I would suggest we consider this for Tomcat 6(my experience is still >>> most users are using this version). >>> >> I have no problem with that. >> >> For Tomcat 7, I would recommend >>> it, as it avoids refactoring, but I'm pretty neutral about it. >>> >> My only concern is that the issue Costin raised regarding scalability >> since this approach retains the HttpProcessor along with the Request and >> Response objects. I don't know how much of an issue scalability is going >> to turn out to be but given the relatively low impact even of the >> generic upgrade changes I think they should be safe. Looking into >> back-porting that is next on my to-do list. >> > That is a valid point. If the chats are long running holding headers in > memory, is a waste. > The other thing to consider for Tomcat 7 is SPDY support in v7, if that is > done using the same mechanism, then that may favor the Tomcat 8 approach I haven't looked at the tomcat6/tomcat7 interfaces, but I think the current hook mechanism used by spdy could be ported with minimal risk and could be used by websockets. All we need in both cases is for the request to stop being processed by the original protocol, and to have direct access to the socket. Than spdy can do its multiplexing and websocket can keep the socket alive and let the original request headers go away. The hard part for spdy backporting is getting the SpdyProcessor - i.e. the virtual/multiplexed request/response, not associated with a real socket. ( which still requires lots of work on trunk, to get the rest of the features - comet, websocket-over-spdy, etc ). Not sure how hard it'll be to backport, but still it shouldn't be very risky. The other problem is the native apr library - but with java7 and jetty's jsse-npn we can do spdy on nio/bio, so it's less of a problem. Costin > > Filip > > > > >> Mark >> >> ------------------------------**------------------------------**--------- >> To unsubscribe, e-mail: >> dev-unsubscribe@tomcat.apache.**org<dev-unsubscr...@tomcat.apache.org> >> For additional commands, e-mail: dev-h...@tomcat.apache.org >> >> >> > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > dev-unsubscribe@tomcat.apache.**org<dev-unsubscr...@tomcat.apache.org> > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
