WebSocket

[Chuck Davis]

Hi Simone:

Thanks for jumping in with your thoughts.

On Mon, Feb 19, 2018 at 12:19 PM, Simone Bordet <simone.bordet at gmail.com>
wrote:

> Hi,
>
> Well, not so fast.
> There are a lot of assumptions in the above code.
> The first is that the ByteBuffer has a backing array, which may not be the
> case.
> If you write the right code that takes care of the possibility that
> the ByteBuffer does not have a backing array, you end up with another
> copy and more code.
> More importantly, the implementation would have done all the copies
> for you in order to feed your code with a final ByteBuffer.
> So you are not really skipping the copies and the performance is not
> different from below, where the possible copies are explicit.
>

Fortunately the Oracle JVM implements a backing array and the code I put
out is exactly from my implementation and has been working superbly for the
last year.  Obviously, the day is approaching when I have to run on openJDK
and I don't know if there is a backing array there since it is optional per
the docs.


> > DONE!  More complicated, messy and very slow.  (i.e. lots of wasted cpu
> cycles)
>
> Nah :)
>
> ByteBufferInputStream bbis = new ByteBufferInputStream();
> for each partial ByteBuffer received by the listener {
>   bbis.add(byteBuffer);
> }
> ois = new ObjectInputStream(bbis);
> MyDTO = ois.readObject();
>
> Now, ByteBufferInputStream is not present in the JDK, and if you want
> to complain you are in good (and conspicuous) company, as the JDK
> engineers appear to avoid the issue since years now (e.g. create a
> String from a ByteBuffer without copy).
> Having said that, the class is trivial to implement (a naive version I
> wrote is about 30 lines) and may even be provided as a utility class
> by the JDK WebSocket implementers.
>
> The advantage is that ByteBufferInputStream can be written in a way
> that performs *zero* copies, thanks to the JDK 9 WebSocket APIs -
> add() would need to return a CompletableFuture.
> If you don't want to confront with CompletableFutures, it can be
> written in a way that performs just one copy.
>

Now we're talking strategy.....go man!!

>
> To sum up:
> * with JDK 9 you need a utility class that you did not need with JDK 8
> * with JDK 9 you can actually perform a zero copy provided you put a
> bit of effort (or the JDK guys do)
> * with JDK 9 the number of byte copies is the same or better
>
> All in all, anything you can do with the JDK 8 API can be done in JDK 9.
> For some cases, JDK 9 is more efficient than JDK 8.
> For all other cases it's on par.
> JDK 9 requires a utility class to convert from ByteBuffer to InputStream.
>

You can do it but being the lazy creature I am I want it done for me....now
they're going to make me do it myself......


>
> Note also that your requirement is to use blocking, stream-based,
> byte[]-based APIs.
> If you had chosen a data format for which a non-blocking parser based
> on ByteBuffer APIs existed, you would be so happy about the JDK 9
> APIs.
>

Like what for instance?  I'm looking for suggestions/strategies how best to
adapt to the future.  It's very unlikely I'm going to convert all my data
to text before sending across the wire.

>
> I have a different experience, where clients may not be able to keep
> up with the network.
> This happens with browsers receiving a message and having to update a
> gazillion DOM nodes (with all the ripple effects that this entails),
> with clients generating so much garbage that the GC is heavily
> interfering with their throughput, with proxy applications that have
> different speeds on the 2 sides they proxy, and so on.
>
> You have my sincerest sympathy.  <opinion> I feel sorry for anybody who
has to interface with that pathetic pile of garbage we refer to as a
browser and it's even more pathetic protocol. </opinion>  You'd think our
industry could do better.



> Here I am seriously advocating to the net-dev JDK group to provide an
> efficient solution, or at least start a discussion where appropriate,
> for ByteBuffer to [Input|Output]Stream that is sorely missing in the
> JDK.
>
> Thanks !
>

Can we start a "Me too" movement? ��

P. S.  If you don't know about our silly American "Me too" movement
consider yourself lucky!

>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20180219/4c41ae8d/attachment.html>