Re: websockets

[Rossen Stoyanchev]

​​hi,

> Simone Bordet:
> As the WebSocket APIs were moved to incubation and are now slated
> for JDK 11, it may be worth considering again whether it's the
> case to provide a Flow-based APIs.

I second that. There were two main issues pointed out in this thread:

> The first one is how to communicate errors back to the user's
> code that publishes messages to WebSocket.

Isn't it mostly low level, transport errors about which the application
can't do much about, but clean up and close the connection? Arguably a
cancellation is adequate, or do you have more specific errors and cases in
mind? Alternatively, the JSR-356 WebSocket API provides a single onError
callback on the Endpoint type. I haven't come across any limitations around
that.

> The second issue is how to communicate completion signals from
> processing individual messages.

James Roper​ mentioned this already, but the Netty PooledByteBufAllocator
demonstrates it's feasible to recycle buffers transparently without the
need for a per-message confirmation. I don't think the argument holds that
not having per message completion signals forces unnecessary allocations,
garbage creation and copying.

There were a "dozen of smaller issues" mentioned. However there were no
links to earlier discussions, so I'm not sure what those were.

The main purpose of Reactive Streams is to connect components from
different libraries. The currently proposed WebSocket API cannot be easily
integrated into a Reactive Streams pipeline. One would have to build a
bridge to Reactive Streams first and I don't think that should be left as a
separate exercise, since Flow is in the JDK and it's the reason why it was
introduced, to provide a common contract for such scenarios.

> Another point that makes me feeling uncertain is the good comment by
> Konrad Malawski about the design of Akka Streams versus e.g. Spring's
> Flowable, where the former does not implement RS or Flow interfaces,
> while the latter does.

One minor clarification first. By "Spring's Flowable" I presume you mean
the Flux and Mono types from the Reactor project? Reactor does not depend
on any Spring projects, and it is a lower level project. It's directly
comparable to RxJava, in fact it implements the same ReactiveX patterns,
but more explicitly targeting server-side Java applications vs Android.

To the point, I don't think the Flow vs RS contracts should a cause for
hesitation. HttpClient already uses the Flow contract and that's the
obvious choice for WebSocket too. More broadly, the JDK Flow and the RS
contracts are identical, and have identical semantics, so adapting from one
to the other is trivial. In most cases applications are not consuming these
contracts directly, which is also Konrad's point, so practically speaking I
don't see much dichotomy there.​

Regards,
Rossen

​

Re: upgrade to jdk6 com.sun.httpserver

[Roger Riggs]

Hi Ashton,

Your optimism seems misplaced;  I heard several suggestions that you 
pick another
web server to depend on.  The http server is an unsupported utility; 
nothing more.


BTW, my mailer marks this email as a possible scam because the link is 
malformed.


Also, the mention of jdk6 is an anachronism; any version less than 8 or 
9 is ancient history

in JDK development.

Regards, Roger

On 2/21/2018 8:39 AM, Ashton Hogan wrote:
Based on the responses received so far, it sounds like there are no 
reservations about the below 4 points. I believe it's safe to assume 
that everyone is in agreement that the below 4 points are good to go with


On Tuesday, 20 February 2018, 16:15:56 GMT, Ashton Hogan 
 wrote:



These items are essential to keeping the server up to date and keeping 
the code at Oracle clean and up to standard:


1. Update to HTTP2
2. Remove excess threads, only one thread is needed
3. Replace handler with a FIFO queue
4. Clean up code, ideally with http://elegantobjects.org 
 principles


If you disagree on any of them please reply with *why *and *what *the 
alternative should be

Re: upgrade to jdk6 com.sun.httpserver

[Ashton Hogan]

 Based on the responses received so far, it sounds like there are no 
reservations about the below 4 points. I believe it's safe to assume that 
everyone is in agreement that the below 4 points are good to go with
On Tuesday, 20 February 2018, 16:15:56 GMT, Ashton Hogan 
 wrote:  
 
  These items are essential to keeping the server up to date and keeping the 
code at Oracle clean and up to standard:

1. Update to HTTP22. Remove excess threads, only one thread is needed3. Replace 
handler with a FIFO queue4. Clean up code, ideally with 
http://elegantobjects.org principles
If you disagree on any of them please reply with why and what the alternative 
should be