On 14/03/2012 17:42, Filip Hanik Mailing Lists wrote:
>
> 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
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.
> 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/
>
> 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.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
