Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-dev] WebSocket + Async Read/Write


On Mon, Feb 13, 2012 at 5:18 PM, Simone Bordet <sbordet@xxxxxxxxxxx> wrote:
Hi Hiram !


Hi Simone!

 
The current API for WebSocket offers blocking writes only. While under
the covers Jetty will do non-blocking writes, the application thread
will be blocked until the application data is fully written.

:-(
 
We may consider a non-blocking API for applications though (of course
a blocking API is way simpler for web applications, but *your* kind of
application is not common, I guess ;).

As for suspend/resume reads I am not sure what you mean. Can you
sketch what you would like to do ?


Well what would be ideal for me is having a connection.suspend()
connection.resume() call which suspends or resumes further onMessage()
calls.
 
The 2 most used interfaces for reading are WebSocket.OnTextMessage and
WebSocket.OnBinaryMessage. Both will coalesce websocket frames until a
final frame is received, then invoke the application.
In order to avoid infinite data, the max text/binary message size can
be configured.

If you want to go deeper, you can implement WebSocket.OnFrame.


No I think you guys framing everything is just fine. 
 
TCP backpressure can be done only via slow readers (implementations of
the interfaces above): we do not offer an API to disable reads. The
parser will aggressively try to read as much as it can and notify the
application, so if the application does nothing the parser will read
more (no way to tell the parser to not read from the socket).

As I said, the API was designed for simple usage, targeted to servlet
developers that want to dive into WebSocket.

Considering that the Servlet 3.0 spec has some async processing support I was hoping some of this would be making it's way into the WebSocket apis too.
 

If you have a different use case (which I can imagine - but better if
you explain it rather than me guessing), we'd love to hear.


My use case is implementing STOMP a messaging protocol over WebSockets for the Apollo messaging server.  Apollo uses a strict async thread model (fixes size thread poll, so you CAN'T ever do a blocking call).  Right now I've lots of extra blocking threads when processing WebSockets connection and it would be nice if I could eliminate those.

But since that's kinda of a complex scenario, the WebSocket proxing scenario works just as well and is something what would be cool if I could see an example of.  Where even if you have congested networks on either side of the proxy, you don't have threads blocked waiting to do writes.
 
Cheers,

Simon
--
http://cometd.org
http://intalio.com
http://bordet.blogspot.com
----
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless.   Victoria Livschitz
_______________________________________________
jetty-dev mailing list
jetty-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jetty-dev



--

Hiram Chirino

Software Fellow | FuseSource Corp.

chirino@xxxxxxxxxxxxxx | fusesource.com

skype: hiramchirino | twitter: @hiramchirino

blog: Hiram Chirino's Bit Mojo





Back to the top