|int||available () throws IOException|
|void||close () throws IOException|
|int||read (byte b) throws IOException|
|int||read (byte b, int off, int len) throws IOException|
|int||read () throws IOException|
|StreamGobbler (InputStream is)|
|byte||buffer = new byte|
|boolean||isClosed = false|
|boolean||isEOF = false|
|int||read_pos = 0|
|final Object||synchronizer = new Object()|
|int||write_pos = 0|
StreamGobbler is an InputStream that uses an internal worker thread to constantly consume input from another InputStream. It uses a buffer to store the consumed data. The buffer size is automatically adjusted, if needed.
This class is sometimes very convenient - if you wrap a session's STDOUT and STDERR InputStreams with instances of this class, then you don't have to bother about the shared window of STDOUT and STDERR in the low level SSH-2 protocol, since all arriving data will be immediatelly consumed by the worker threads. Also, as a side effect, the streams will be buffered (e.g., single byte read() operations are faster).
Other SSH for Java libraries include this functionality by default in their STDOUT and STDERR InputStream implementations, however, please be aware that this approach has also a downside:
If you do not call the StreamGobbler's
read() method often enough and the peer is constantly sending huge amounts of data, then you will sooner or later encounter a low memory situation due to the aggregated data (well, it also depends on the Java heap size). Joe Average will like this class anyway - a paranoid programmer would never use such an approach.
The term "StreamGobbler" was taken from an article called "When Runtime.exec() won't", see http://www.javaworld.com/javaworld/jw-12-2000/jw-1229-traps.html.