You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Filip Hanik Mailing Lists <de...@hanik.com> on 2012/03/14 18:42:25 UTC
WebSockets in Tomcat 6
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
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
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.
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). For Tomcat 7, I would recommend it, as it avoids refactoring, but I'm pretty neutral about it.
Filip
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: WebSockets in Tomcat 6
Posted by Filip Hanik Mailing Lists <de...@hanik.com>.
----- Original Message -----
> From: "Costin Manolache" <co...@gmail.com>
>
> 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.
Tomcat 7 may be a candidate. Tomcat 6, If I was an administrator, I would not expect any code changes like that in a dot release.
>
> 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.
Yes, I'd like to see some real numbers on the request header overhead. I doubt it will be an issue for Tomcat 6. For Tomcat 7 large refactorings and optimzations are happening all the time, so in there it makes sense.
>
> 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.
As I just got back into the code mode of Tomcat, I'll look forward to take a look and see how it progresses.
Filip
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: WebSockets in Tomcat 6
Posted by Costin Manolache <co...@gmail.com>.
On Thu, Mar 15, 2012 at 7:10 AM, Filip Hanik - Dev Lists <devlists@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<de...@tomcat.apache.org>
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>>
>>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.**org<de...@tomcat.apache.org>
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: WebSockets in Tomcat 6
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: WebSockets in Tomcat 6
Posted by Mark Thomas <ma...@apache.org>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org