AsynchronousByteCharChannel and Timeouts
libman at terabit.com.au
Mon Aug 3 21:23:05 PDT 2009
In addition to Alan comments.
we can consider timed operations as a contract to finish operation in
specified time interval.
Timeout error can be interpereted as kind of execution error and it leaves
the channel in undefined state.
This is major difference between asynchronous and sychnoronous non-blocking
ways of programming.
For the algorithms when the content of the next portion data to send
depends depends not only on peer reply,
but also on the time of reply arrival or timeouts, we have to inroduce
imaginable "AsynchronousTimers" with completion handlers.
Currently, we can use Timer and TimerTask in java.util as
"AsynchronousTimer" and CompletionHandler.
Usually, the Completion Handler invocation works as signal for protocol
Now, we simply add the number of signals to our state machine.
The main advantages are :
1) the single TimerTask can be used as signal for several channels, i.e.
"watch dog" approach.
Would be nice, if the user can facility to register the watch dog time
interval and timer task for whole AsynchronousGroup.
This task can iterate over group channel and for each channel invoke a
Inside such callback the developer can calculate the time expired from the
last started read/write operations.
2) very often we are not interested in time interval for particular I/O
operation, but rather we are inetresrted in transition from state A to state
B in specified time interval.
Between states A and B, it can be executed a lot of read/write operations.
AsynchronousTimer approach allows to resolve this task and keep the channel
in consistent state if we decide to change our actions in timed manner.
I am not sure do we want timed operations for artificial
AsynchronousChannels (Filters). Example, AsynchronousSSLChannel.
We have different timeout meaning for external and internal channels.
Support of general timeouts for the filters -I think it is too much
Independent AsynchronousTimer makes life easy here as well.
For SerialPort communications AsynchrnousTimer aprproach works too.
You can setup: "A value of zero for both the ReadTotalTimeoutMultiplier and
ReadTotalTimeoutConstant members indicates that total time-outs are not used
for read operations."
Or it is possible to use both Windows Comm timeouts to control the rate of
arriving bytes (like for low level data link protocol ) and high
level-timeouts "Timers" for the application layer.
> -----Original Message-----
> From: nio-discuss-bounces at openjdk.java.net
> [mailto:nio-discuss-bounces at openjdk.java.net]On Behalf Of Alan Bateman
> Sent: Monday, August 03, 2009 4:15 PM
> To: Gili
> Cc: nio-discuss at openjdk.java.net
> Subject: Re: AsynchronousByteCharChannel and Timeouts
> Gili wrote:
> > :
> > Here is a simple counter-example that comes to mind:
> > write() to request a computation on the remote end
> > read() with a timeout waiting for the result
> > if a timeout occurs, write() telling the queue to abort the computation
> > In the above case you could disconnect on timeout, reconnect
> and request an
> > abort. Forcing a disconnect on a timeout is not the end of the
> world, but it
> > seems like an unnecessary limitation. Instead of invalidating
> the channel,
> > couldn't you have specified that in case of a timeout the API
> will return
> > the number of bytes that were written by the underlying implementation
> > (ideally zero) and leave it up to the user to decide if he wishes to
> > disconnect or do something else?
> AsynchronousSocketChannel doesn't close the channel on timeout. Rather
> it just invokes the completion handler's failed method with the
> InterruptedByTimeoutException. In many cases the application will close
> the channel at this point because the peer is not responding and there
> is nothing it can do. The wording in the spec related to continued use
> of the channel is to deal with possible implementations where it is
> completely unfeasible to cancel an I/O operation and leave the
> connection and channel is a consistent state. For example, suppose an
> implementation is using blocking I/O then there may be thread blocked in
> read or write and no way to unblock it cleanly. Another example may be
> where it is possible to cancel an I/O but have no way to guarantee that
> bytes haven't been transferred in/out of the socket buffer. That would
> completely break stream communication and clearly this an area where
> serial port I/O will differ (because you are at lower level and I assume
> there is some protocol to over errors, right?. In other words, the
> protocol will recover from data loss and other protocol errors).
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.5.392 / Virus Database: 270.13.43/2280 - Release Date:
> 08/03/09 17:56:00
More information about the nio-discuss