Re: WebSockets in Tomcat 6

2012-03-16 Thread Filip Hanik Mailing Lists


- Original Message -
 From: Costin Manolache cos...@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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



Re: WebSockets in Tomcat 6

2012-03-15 Thread Mark Thomas
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



Re: WebSockets in Tomcat 6

2012-03-15 Thread Filip Hanik - Dev Lists

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



Re: WebSockets in Tomcat 6

2012-03-15 Thread Costin Manolache
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.patchhttp://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.**orgdev-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: dev-h...@tomcat.apache.org




 --**--**-
 To unsubscribe, e-mail: 
 dev-unsubscribe@tomcat.apache.**orgdev-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: dev-h...@tomcat.apache.org




WebSockets in Tomcat 6

2012-03-14 Thread Filip Hanik Mailing Lists

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