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