Is it possible to read from a Java InputStream with a timeout?

Specifically, the problem is to write a method like this:

int maybeRead(InputStream in, long timeout)

where the return value is the same as in.read() if data is available within 'timeout' milliseconds, and -2 otherwise. Before the method returns, any spawned threads must exit.

To avoid arguments, the subject here java.io.InputStream, as documented by Sun (any Java version). Please note this is not as simple as it looks. Below are some facts which are supported directly by Sun's documentation.

1. The in.read() method may be non-interruptible.

2. Wrapping the InputStream in a Reader or InterruptibleChannel doesn't help, because all those classes can do is call methods of the InputStream. If it were possible to use those classes, it would be possible to write a solution that just executes the same logic directly on the InputStream.

3. It is always acceptable for in.available() to return 0.

4. The in.close() method may block or do nothing.

5. There is no general way to kill another thread.

From stackoverflow

• Note that the documentation states that the default implementation of available() always returns 0, but that available should be overridden in inheriting classes... And with the limitation that you can't leave any spawned threads, using available would seem to be your only solution.

• I have not used the classes from the Java NIO package, but it seems they might be of some help here. Specifically, java.nio.channels.Channels and java.nio.channels.InterruptibleChannel.

  Eddie : +1: I don't believe that there is a reliable way to do what the OP is asking for with InputStream alone. However, nio was created for this purpose, among others.

• As jt said, NIO is the best (and correct) solution. If you really are stuck with an InputStream though, you could either

  1. Spawn a thread who's exclusive job is to read from the InputStream and put the result into a buffer which can be read from your original thread without blocking. This should work well if you only ever have one instance of the stream. Otherwise you may be able to kill the thread using the deprecated methods in the Thread class, though this may cause resource leaks.

  2. Rely on isAvailable to indicate data that can be read without blocking. However in some cases (such as with Sockets) it can take a potentially blocking read for isAvailable to report something other than 0.

• Here is a way to get a NIO FileChannel from System.in and check for availability of data using a timeout, which is a special case of the problem described in the question. Run it at the console, don't type any input, and wait for the results. It was tested successfully under Java 6 on Windows and Linux.

  import java.io.FileInputStream;
  import java.io.FilterInputStream;
  import java.io.IOException;
  import java.io.InputStream;
  import java.lang.reflect.Field;
  import java.nio.ByteBuffer;
  import java.nio.channels.ClosedByInterruptException;
  
  public class Main {
  
      static final ByteBuffer buf = ByteBuffer.allocate(4096);
  
      public static void main(String[] args) {
  
          long timeout = 1000 * 5;
  
          try {
              InputStream in = extract(System.in);
              if (! (in instanceof FileInputStream))
                  throw new RuntimeException(
                          "Could not extract a FileInputStream from STDIN.");
  
              try {
                  int ret = maybeAvailable((FileInputStream)in, timeout);
                  System.out.println(
                          Integer.toString(ret) + " bytes were read.");
  
              } finally {
                  in.close();
              }
  
          } catch (Exception e) {
              throw new RuntimeException(e);
          }
  
      }
  
      /* unravels all layers of FilterInputStream wrappers to get to the
       * core InputStream
       */
      public static InputStream extract(InputStream in)
              throws NoSuchFieldException, IllegalAccessException {
  
          Field f = FilterInputStream.class.getDeclaredField("in");
          f.setAccessible(true);
  
          while( in instanceof FilterInputStream )
              in = (InputStream)f.get((FilterInputStream)in);
  
          return in;
      }
  
      /* Returns the number of bytes which could be read from the stream,
       * timing out after the specified number of milliseconds.
       * Returns 0 on timeout (because no bytes could be read)
       * and -1 for end of stream.
       */
      public static int maybeAvailable(final FileInputStream in, long timeout)
              throws IOException, InterruptedException {
  
          final int[] dataReady = {0};
          final IOException[] maybeException = {null};
          final Thread reader = new Thread() {
              public void run() {                
                  try {
                      dataReady[0] = in.getChannel().read(buf);
                  } catch (ClosedByInterruptException e) {
                      System.err.println("Reader interrupted.");
                  } catch (IOException e) {
                      maybeException[0] = e;
                  }
              }
          };
  
          Thread interruptor = new Thread() {
              public void run() {
                  reader.interrupt();
              }
          };
  
          reader.start();
          for(;;) {
  
              reader.join(timeout);
              if (!reader.isAlive())
                  break;
  
              interruptor.start();
              interruptor.join(1000);
              reader.join(1000);
              if (!reader.isAlive())
                  break;
  
              System.err.println("We're hung");
              System.exit(1);
          }
  
          if ( maybeException[0] != null )
              throw maybeException[0];
  
          return dataReady[0];
      }
  }
  

  Interestingly, when running the program inside NetBeans 6.5 rather than at the console, the timeout doesn't work at all, and the call to System.exit() is actually necessary to kill the zombie threads. What happens is that the interruptor thread blocks (!) on the call to reader.interrupt(). Another test program (not shown here) additionally tries to close the channel, but that doesn't work either.