Skip to main content

[jsr356-experts] Re: [jsr356-users] Re: Streaming Options

  • From:
  • To: " " < >
  • Cc: " " < >
  • Subject: [jsr356-experts] Re: [jsr356-users] Re: Streaming Options
  • Date: Fri, 13 Jul 2012 08:25:16 -0500

Looking at the other services API, it looks like at the minimum we need 
To implement option # 1 and option # 3c

Where we need synch and asynchronous support. Option #2 seems 
To be good but looks complex as the main thread have to be blocked
Until the whole message comes back. I would go with option #2
If we are reading big blog data.

It would be good to extend as some people like the data read byte 
By byte for better performance.

Thanks
Naveen



On Jul 12, 2012, at 9:23 PM, Joe Walnes < "> > wrote:

I'm also a fan of 3B with 1 layered on top for convenience.

On Thu, Jul 12, 2012 at 6:46 PM, Danny Coward < " target="_blank"> > wrote:
Hi folks,

I'm going try to to reduce the thread on the various options on the streaming apis we've chewed on over the last week into three options. I *think* everyone agrees that applications should listen for incoming messages, rather than block until one arrives. Right ? So I think that leaves us with these three modes (below) for processing messages. (And note that I think we agree that nothing in the API is supposed to dictate anything about how the implementation uses web socket framing underneath.)

mode
receive description
possible receive API
send description
possible send API
1. "whole messages"
listen for incoming messages, get message all at once onMessage(String string)
onMessage(byte[] bytes)
send whole messages send(String string)
send(byte[] bytes)
2. "blocking read/writes"


listen for incoming messages, read message from stream using blocking calls onMessage(InputStream is) { ... byte b = is.read(); ...}
onMessage(Reader r) {  ...  int c = r.read();   ... }
open send stream, blocking writes to the stream OutputStream getSendStream()
Writer getSendWriter()
3. "async processing"
 

listen for incoming message, receive message from stream asynchronously Option A) onMessage(AsynchronousByteChannel abc)  {  abc.read(bytebuffer, attachment, completionhandler) }

Option B) 1 or more calls to onMessage(String partialString, boolean isLast) or onMessage(byte[] partialBytes, boolean isLast)

Option C) servlet 3.1-style special IO streams that allow non-blocking reads.
initiate outgoing message, message pulled on demand by the stream Option A) AsynchronousByteChannel getAsyncChannel()

Option B) 1 or more calls to send(String partialString, boolean isLast) or send(byte[] partialBytes, boolean isLast).

Option C) servlet 3.1-style special IO streams that allow non-blocking writes.


So I think in terms of what goes in the JSR API, mode (1) I think is a no-brainer for bread and butter applications, although obviously (1) alone would not be enough. I think Scott made a good case for (2) in terms of making it easy to use other libraries that assume traditional IO. I also think we should expose some form of mode (3), for frameworks that build on the API. I don't think it has to be either 2 or 3: it can be both.

Of the choices in mode (3), I'd probably go for option A). However, I do think many developers (me at least, but not Greg!) find the NIO APIs awkward, so can see a benefit in the simplicity of option B). The servlet style of specializing the Java IO APIs to allow non-blocking IO seems on the face of it to be overly elaborate for our needs, so I like option (c) least.

- Danny
--
Danny Coward
Java EE
Oracle Corporation



[jsr356-experts] Streaming Options

Danny Coward 07/12/2012

[jsr356-experts] Re: [jsr356-users] Streaming Options

Scott Ferguson 07/13/2012

[jsr356-experts] Re: Streaming Options

Greg Wilkins 07/13/2012

[jsr356-experts] Re: [jsr356-users] Re: Streaming Options

Scott Ferguson 07/13/2012

[jsr356-experts] Re: [jsr356-users] Re: Streaming Options

Greg Wilkins 07/13/2012

[jsr356-experts] Re: [jsr356-users] Re: Re: Streaming Options

Scott Ferguson 07/13/2012

[jsr356-experts] Re: [jsr356-users] Re: Re: Streaming Options

Greg Wilkins 07/14/2012

<Possible follow-up(s)>

[jsr356-experts] Streaming Options

Danny Coward 07/12/2012

[jsr356-experts] Re: Streaming Options

Joe Walnes 07/13/2012

[jsr356-experts] Re: [jsr356-users] Re: Streaming Options

navraj . reddy 07/13/2012

[jsr356-experts] Re: [jsr356-users] Re: Streaming Options

Justin Lee 07/13/2012

[jsr356-experts] Re: Streaming Options

Remy Maucherat 07/13/2012
 
 
Close
loading
Please Confirm
Close