JDK-4467752 : java.nio.channels for java.lang.Process-IO
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.io
  • Affected Version: 1.4.0
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • OS: generic
  • CPU: generic
  • Submitted: 2001-06-08
  • Updated: 2017-02-24
Related Reports
Relates :  
Description

Name: bsC130419			Date: 06/08/2001


java version "1.4.0-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-beta-b65)
Java HotSpot(TM) Client VM (build 1.4.0-beta-b65, mixed mode)



java.nio.channels are the solution to the one-thread-per-input (or
-output)-problem, but they only solve that problem for network-IO. When java is
used to call other applications by using java.lang.Runtime.exec(), every started
process needs up to 3 (three) threads (stdin, stdout, stderr). This is very
expensive, especially if multiple processes are called simultaneously. There
should be a way to minimize "administration" of IO with other processes on the
system.

The same applies to file-IO: File IO can be time-expensive, (especially for
network file systems) too. So read() and write() of FileChannel should be
selectable.

There might also be a design bug of FileChannel.force(): This method serves two,
not one functions:

(1) hurry file data to disk
(2) inform the application that file data is saved on disk

These functions must be separated. Imagine a heavily loaded mail server which
stores incoming e-mail into a file. When the SMTP DATA command completes, the
SMTP client must be sure that it may forget about that message because the SMTP
server stores it somewhat reliably. That's why an SMTP server would call
FileChannel.force(). But this has the bad consequence that the file data is
forced as soon as possible to disk, not two or three seconds later, where it
would be much more economic (better file allocation strategies, sorted block
writes -> short seeks between writes, etc.). This problem results in a drastic
throughput loss, which is not necessary.

FileChannel.force() should (in non-blocking-mode) just request a sync-to-disk.
FileChannel.force(long limitTime) should give the OS an upper limit (for example
30000 milliseconds) of when at the latest the sync-to-disk should be initiated.
There should be a constant SelectionKey.OP_SYNC, which, if set, informs the
application about the arrival of data on persistent storage.

This will also be workable across network filesystems.

I know, only few OSs already make the distinction between sync-to-disk and
inform-about-sync-to-disk, but regarding the future, java could do it right just
from the start and emulate if necessary.
(Review ID: 126090) 
======================================================================