If you've been following the issues, you will have seen that I've
finally been able to address a number of long standing issues with
websockets on the trunk. Specifically today, i'm tackling
https://grizzly.dev.java.net/issues/show_bug.cgi?id=841. This one has
never sat well with and I'm going to clean that up. Here's what I'm
thinking. I'm going to remove all notion of IO from the WebSocket on
the server. (Client obviously still has to deal with stuff). Already
on the server, we have an object capturing the key selection events and
notifying the WebSocket object to read an unframe data. I want to move
this out so that all the reading from the wire is done outside the
WebSocket object. Once the data is read, the DataFrame will be passed
to the WebSocket to handle as it wishes.
Going the other way, the WebSocket will build the DataFrame and notify
the WebSocketEngine that it's ready to send. The WSE will have at least
one thread to handle the actual writing of messages out to the client.
This will give us an NIO-oriented approach to sending data while
simultaneously simplifying any server side WebSocket classes. It also
makes testing these classes *really* simple as there is no network layer
that needs to be mocked away. It also paves the way for dramatically
simplifying the internal code as it would potentially let us refactor
the client and server sides to much more common code. (The difference
being the handling of network traffic).
Hopefully this makes sense. If there are any objections, please speak
up as I'm trying this now to test its general feasibility. It should
work rather nicely and clean up the code quite a bit as well. If there
are no objections, and if this approach works, it should be in svn in a
day or two.
Now's the time to speak up, though. :)