There is a great hush here regarding strategy for putting the pieces
back together so here goes my tirade.
Following is based on assumption of a 100k payload.
With jdk8:
The decoder received a ByteBuffer
bais = new ByteArrayInputStream(ByteBuffer.array()); // wrap the
buffer -- optional method but implemented in Oracle JVM
ois = new ObjectInputStream(bais) // wrap the input stream
MyDTO = ois.readObject(); // deserialize the object (which may
contain hundreds or thousands of objects)
DONE! Simple, clean and blazingly fast.
With jdk9:
The Listener receives a ByteBuffer (I read someplace the default size
is potentially going to be 256 bytes)
If it's the first part (or whole) create a byte[] of 10k (or whatever)
Start copying bytes from the buffer to the array
Check each byte to be sure there is room in the array for another byte
if room, copy the byte
if no room, copy the array to a larger array (current size + 10k)
and then copy the byte
repeat until all messages are processed (i.e. each byte will have
been copied somewhere between 1 and 10 times)
bais = new ByteArrayInputStrea(byte[]);
ois = new ObjectInputStream(bais);
MyDTO = ois.readObject();
DONE! More complicated, messy and very slow. (i.e. lots of wasted cpu cycles)
RESULT: The formerly fabulous WebSocket has been rendered relatively
useless as a platform for building responsive, bidirectional
client/server applications. Am I the only person who sees this as a
HUGE regression of functionality?? I am ALARMED by this turn of
events.
OPINION:
I'm pretty naive about the world of midrange and mainframe except that
they can throw a lot of bytes in a short time. But I imagine the
choke-point of any desktop application is going to be the network.
Unless somebody is running a Pentium I doubt any relatively modern
desktop is going to have a difficult time keeping up with networking
speeds. It seems to me, therefore, that backpressure in WebSocket is
a solution looking for a problem. If backpressure is somehow
essential in WebSocket include the possibility but please don't
destroy the best client/server communication in the process. If
necessary, create two implementations: WebSocketFast and
WebSocketSlow.
I'll go back to my cave now and pout about what has happened to my
once fabulous WebSocket.
