AsynchronousCharChannel

[Gili]

Hi,

I just wanted to let you know I'm almost done implementing a AsynchronousCharChannel that takes a AsynchronousByteChannel as input and provides the following functionality:

read/write CharBuffer
readLine()

I hope no one else is working on the same thing... When I'm done, is there a chance this will end up in the official NIO2 release?

Gili

[Alan Bateman]

Gili wrote:

> Hi,
>
> I just wanted to let you know I'm almost done implementing a
> AsynchronousCharChannel that takes a AsynchronousByteChannel as input and
> provides the following functionality:
>
> read/write CharBuffer
> readLine()
>
> I hope no one else is working on the same thing... When I'm done, is there a
> chance this will end up in the official NIO2 release?
>
> Gili
>  

Alex Libman has built a filter framework on this API and it includes an
AsynchronousCoder for char I/O. You might want to bring it up on the
nio-dev mailing list for more discussion.

-Alan.

[Gili]

I found Alex's JProactor framework here: http://jproactor.svn.sourceforge.net/viewvc/jproactor/trunk/nio2/src/au/com/terabit/nio2/filter/

I have two problems with AsynchronousCoder.

1) The code is sparsely documented.
2) It's too "abstract". I'm looking for a practical/simple solution to a common use-case.

I don't think it makes sense to implement readLine() the same way as read(CharBuffer) because in the former case you know how many characters the buffer must contain whereas in the latter case you have no idea how long the line will be. That's why BufferedReader.readLine() returns a String instead of taking in a char[].

Anyway, I think we better wait until I finish implementing this API. Once I'm done I will post the code for your review and you can judge how well it fits (or not) alongside NIO2.

Thank you,
Gili

Alan Bateman wrote:

Gili wrote:
> Hi,
>
> I just wanted to let you know I'm almost done implementing a
> AsynchronousCharChannel that takes a AsynchronousByteChannel as input and
> provides the following functionality:
>
> read/write CharBuffer
> readLine()
>
> I hope no one else is working on the same thing... When I'm done, is there a
> chance this will end up in the official NIO2 release?
>
> Gili
>  
Alex Libman has built a filter framework on this API and it includes an
AsynchronousCoder for char I/O. You might want to bring it up on the
nio-dev mailing list for more discussion.

-Alan.

[Gili]

As promised, here are two classes for your review: AsynchronousCharChannel and AsynchronousByteCharChannel.

1) I'm looking for a better name than "AsynchronousByteCharChannel"
2) I'd like suggestions on how to clean up the implementation to improve readability and remove duplication.
3) To compile the code, simply replace imports from "jperipheral.nio.channels.*" to "java.nio.channels.*"

Please take a look and send me some feedback.

Thank you,
Gili

AsynchronousCharChannel.java
AsynchronousByteCharChannel.java

[Alan Bateman]

Gili wrote:

> As promised, here are two classes for your review: AsynchronousCharChannel
> and AsynchronousByteCharChannel.
>
> 1) I'm looking for a better name than "AsynchronousByteCharChannel"
> 2) I'd like suggestions on how to clean up the implementation to improve
> readability and remove duplication.
> 3) To compile the code, simply replace imports from
> "jperipheral.nio.channels.*" to "java.nio.channels.*"
>
> Please take a look and send me some feedback.
>
> Thank you,
> Gili
>
> http://n2.nabble.com/file/n3193571/AsynchronousCharChannel.java
> AsynchronousCharChannel.java
> http://n2.nabble.com/file/n3193571/AsynchronousByteCharChannel.java
> AsynchronousByteCharChannel.java
>  

I haven't had a chance to look at this in any detail but I wonder if you
really need write(... boolean endOfInput)? That is, do you really need
the equivalent of a half-close (as in TCP) or isn't close sufficient?

-Alan.

[Gili]

Alan Bateman (via Nabble) wrote:
> I haven't had a chance to look at this in any detail but I wonder if you
> really need write(... boolean endOfInput)? That is, do you really need
> the equivalent of a half-close (as in TCP) or isn't close sufficient?

        Good point. I'll update this in the next release.

        I'm also looking for a way to use a more generic argument for
readLine(). Right now I reference StringBuilder explicitly because:

- Passing in CharBuffer (which is Appendable) is questionable because
you're likely to run into BufferedOverflowException.
- I need to know how many characters were written into the buffer. I can
either butcher CharSequenceWriter to expose this information or use
something like <T extends Appendable & CharSequence> but the latter
wasn't working so cleanly because CharBuffer.length() ==
CharBuffer.remaining(). Meaning it gets smaller as more data is written
to it, whereas StringBuilder.length() gets longer as more data is
written to it, so it makes it impossible to use CharSequence.length()
consistently to find out how many characters were written.

Gili

[Alan Bateman]

Gili wrote:
> :
>         I'm also looking for a way to use a more generic argument for
> readLine(). Right now I reference StringBuilder explicitly because:
An alternative is to simply return the line as a String, as in:
  Future<String> result = channel.readLine();

-Alan.

[Gili]

Alan Bateman (via Nabble) wrote:
> I haven't had a chance to look at this in any detail but I wonder if you
> really need write(... boolean endOfInput)? That is, do you really need
> the equivalent of a half-close (as in TCP) or isn't close sufficient?

        Actually, I just realized... what happens if the last write() triggers
a flush() that just so happens to trigger the remote end sending bytes
back? If close() means flushes the output, then the receiving end never
has a chance of picking up those last incoming bytes. Is this a
reasonable use-case?

Thanks,
Gili

[Alan Bateman]

Gili wrote:

> Alan Bateman (via Nabble) wrote:
> > I haven't had a chance to look at this in any detail but I wonder if
> you
> > really need write(... boolean endOfInput)? That is, do you really need
> > the equivalent of a half-close (as in TCP) or isn't close sufficient?
>
>         Actually, I just realized... what happens if the last write()
> triggers
> a flush() that just so happens to trigger the remote end sending bytes
> back? If close() means flushes the output, then the receiving end never
> has a chance of picking up those last incoming bytes. Is this a
> reasonable use-case?

Yep, close is complicated. Your filter will probably need a timer so
that if close initiates a write then the timer can be used to close the
wrapped channel if the write doesn't complete within a reasonable time.
You'll probably need this anyway, even if you have the equivalent of
shutdownOutput. Issues such as the peer sending data at around the time
that you close the channel are of course possible, and likely indicate a
protocol issue. On the "receiving end" attempts to read from the channel
will fail with ClosedChannelException (as you would expect).

-Alan.