Jetty-WebSocket sendMessage api was blocking

[wsky]

jetty vs netty websocket:

jetty sendMessage is block, high cpu and low memory usage.

netty full async but memory usage higher, you need to resolve OOM while network is congestion, you need more buffers，but it can easy as more as using bandwidth.

how about both strategy for web server?

see sourcecode:
http://jetty.4.n6.nabble.com/jetty-dev-WebSocket-Async-Read-Write-td4466406.html

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. 

Sure, this is pretty much like JDK 7's Async IO. 

https://github.com/eclipse/jetty.project/blob/jetty-8.1.7.v20120910/jetty-websocket/src/main/java/org/eclipse/jetty/websocket/WebSocketGeneratorRFC6455.java#L83
buffersize will course hight cpu usage while buffer is too small

https://github.com/eclipse/jetty.project/blob/jetty-8.1.7.v20120910/jetty-websocket/src/main/java/org/eclipse/jetty/websocket/WebSocketServlet.java#L64
String bs = getInitParameter("bufferSize");
_webSocketFactory = new WebSocketFactory(this, bs == null ? 8192 : Integer.parseInt(bs));
8192Byte
http://tutorials.jenkov.com/java-servlets/web-xml.html
buffersize tuning：
up to 100M, then memory usage up to 1.4G, throughput up a little fast，but cpu still high.
up to 10M，then mem 350M，throughput bigger than 100M，cpu high
up to 1M then mem 160M，throughput same as 10M's，cpu high

other:
jetty-websocket build-in client slower than nodejs, so poor.