Need an InputStream with Timeout (or equivalent)

K

Knute Johnson

Gilbert said:
Hi

I (think I) need an InputStream implementation that provides a timeout
facility.

I'm currently working with a proprietary serial device that, when a command
is written to the serial output stream, will eventually return one or more
data blocks. Each block will be "guaranteed" to be returned within a time
period (t). (i.e the device will not necessarily return an immediate
response). Once each block is returned the timer should re-set and the next
block will return in time(t).

So far, I have implemented the serial interface using the RxTx package.
(as an aside, kudos to the developers - research suggested that implementing
serial comms in Java was going to be a nightmare.) The RxTx package has made
things very easy and presents comms with the serial port through their own
InputStream and OutputStream implementations.

Preliminary testing has shown that the traditional
"while (data = input,read() > -1)" doesn't work here as the RxTx
implementation will always return -1 if there is no data available rather
than block until data is present and input.available() will return 0 if
there is no data (as expected). I got my first pass at this to work by
inserting Thread.sleep() commands but obviously this is not ideal.

That's because RxTx has a serious bug (that they have refused to fix for
years) and will not reliably do blocking I/O. Use Sun's implementation
if you want it to work.
I then found that the SerialEventListner facility makes it easy to
cater for responses that don't happen immediately by notifying when there
is something on the serial input stream to read.

But, unless I'm missing something, neither of these methods will cater for
the situation where the device completely fails to respond within time(t)
- which according to the device specs is a hard-failure from which the
device will not recover.

Googling has suggested two possible routes. Older messages prior to the
introduction of the NIO package suggest a convoluted method of creating a
timer thread to monitor the buffer that should be filled by the serial input
stream. Later posts suggest that using NIO is the way to go.

I've never used the NIO package and info I've found on Google suggest that
this is may not be an easy thing to do.

So my questions are these;

1) Is a timeout enabled InputStream what I need?
2) Assuming Yes - is there an implementation available somewhere? (I've
tried Apache-Commons, the usual first stop but found nothing)
3) Is there a tutorial available that will guide me through my first
dealings with NIO.

Regards

Look at Sun's Comm API. It has receive timeouts built in.

Sun no longer supports their Windows version of Comm API but it still
works just fine on XP at least and probably on Vista as well although I
haven't tested it. Sun does have a Linux and Solaris APIs that are current.
 
G

Gilbert

Hi

I (think I) need an InputStream implementation that provides a timeout
facility.

I'm currently working with a proprietary serial device that, when a command
is written to the serial output stream, will eventually return one or more
data blocks. Each block will be "guaranteed" to be returned within a time
period (t). (i.e the device will not necessarily return an immediate
response). Once each block is returned the timer should re-set and the next
block will return in time(t).

So far, I have implemented the serial interface using the RxTx package.
(as an aside, kudos to the developers - research suggested that implementing
serial comms in Java was going to be a nightmare.) The RxTx package has made
things very easy and presents comms with the serial port through their own
InputStream and OutputStream implementations.

Preliminary testing has shown that the traditional
"while (data = input,read() > -1)" doesn't work here as the RxTx
implementation will always return -1 if there is no data available rather
than block until data is present and input.available() will return 0 if
there is no data (as expected). I got my first pass at this to work by
inserting Thread.sleep() commands but obviously this is not ideal.

I then found that the SerialEventListner facility makes it easy to
cater for responses that don't happen immediately by notifying when there
is something on the serial input stream to read.

But, unless I'm missing something, neither of these methods will cater for
the situation where the device completely fails to respond within time(t)
- which according to the device specs is a hard-failure from which the
device will not recover.

Googling has suggested two possible routes. Older messages prior to the
introduction of the NIO package suggest a convoluted method of creating a
timer thread to monitor the buffer that should be filled by the serial input
stream. Later posts suggest that using NIO is the way to go.

I've never used the NIO package and info I've found on Google suggest that
this is may not be an easy thing to do.

So my questions are these;

1) Is a timeout enabled InputStream what I need?
2) Assuming Yes - is there an implementation available somewhere? (I've
tried Apache-Commons, the usual first stop but found nothing)
3) Is there a tutorial available that will guide me through my first
dealings with NIO.

Regards
 
G

Gilbert

Look at Sun's Comm API.  It has receive timeouts built in.

Sun no longer supports their Windows version of Comm API but it still
works just fine on XP at least and probably on Vista as well although I
haven't tested it.  Sun does have a Linux and Solaris APIs that are current.

I don't suppose that you have a url available do you? I'm having
problems in locating the download.

Regards
 
K

Knute Johnson

Gilbert said:
I don't suppose that you have a url available do you? I'm having
problems in locating the download.

Regards

Do you want the Windows version? If your address on your post will take
an email and attachment, I'll send it to you. It's 267k. Or email me
and I'll send it. Swap nospam and knute2009 in my address.
 
R

Roedy Green

I'm currently working with a proprietary serial device that, when a command
is written to the serial output stream, will eventually return one or more
data blocks.

You might look for a serial i/o package that directly supports
timeouts, rather than trying to build them into your InputStream.

The i/o would simply fail with an exception
on timeout.

see http://mindprod.com/jgloss/serialport.html
 
R

Roedy Green

The links to the Sun version on your page link to a nice page with the Sun
logo and ... nothing else - they're completely blank

Thanks. I get a partial page. I have removed those links. My link
checker fails to notice them as broken since Sun returns a 200 OK on
them.
 
G

Gilbert

Roedy said:
You might look for a serial i/o package that directly supports
timeouts, rather than trying to build them into your InputStream.

The i/o would simply fail with an exception
on timeout.

see http://mindprod.com/jgloss/serialport.html

The links to the Sun version on your page link to a nice page with the Sun
logo and ... nothing else - they're completely blank.

Actually, when I was talking about timing out, I was thinking in terms of
an exception, rather than releasing control to the inputstream which is
what both the RxTx and Sun implementations do (Yes, I eventually found it)

The Sun implementation actually seems to work quite well. Enabling the
timeout and disabling the threshold works as documented by the api. RxTx
doesn't - that applies the timeout to all read access to the inputstream
regardless of whether data becomes available in the meantime.

One area of concern that came to light while trying to find the Sun
package was a post - and I can't remember the URL - that the End Of
Life license that currently applies to the Windows version of the api
means that I cannot distribute it. Anyone know anything about this?

Regards


whether
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top