Atsuhiko Yamanaka wrote:
> +-From: Timothy Webb <tiwebb@...> --
> |_Date: Mon, 15 Nov 2004 21:55:33 -0500 __
> |Issue 1: Using multiple threads with ChannelSftp
> |When using ChannelSftp, I was using a thread pool to handle
> |requests and issue commands against ChannelSftp. Since
> |ChannelSftp uses piped input and output streams to handle the
> |coordination with the underlying channel, each time one of the
> |threads indirectly reads from the underlying piped input stream,
> |the "readSide" gets updated. If that thread happens to die before
> |another thread reads from the ChannelSftp, this can cause an
> |incorrect error in the stream indicating "Read end dead".
>I have not understood clearly yet, but do you mean that multiple
>threads in your program will get access to one stream simultaneously?
Essentially... ChannelSftp is saved as a static. Multiple threads are
accessing it (synchronizing on it at any given time ensuring thread-safe
usage). They take turns performing operations such as gets, puts and
Since PipedInputStream keeps track of the last thread, if the last
thread to use it dies before another one begins using it, then the
PipedOutputStream assumes the other side is dead and ultimately the
entire SSH Session is disconnected. By replacing the PipedIn/OutStreams
with ones that don't monitor the thread "isAlive()" of it's pair, the
code works as intended.
> |To get around this, I implemented my own PipedInput /
> |OutputStreams that didn't do the thread checking. This causes my
> |test to run successfully but does have the potential for
> |indefinitely blocking a thread if no one is writing / reading from
> |the otherside.
>Anyway, I'll agree with you that piped I/O streams in JDK have problems
>and they should be replaced with others in several point of views.
> |Issue 2: Timing hole on close(...) when using
> |ChannelSftp.put(....) : OutputStream
> |The OutputStream returned from ChannelSftp.put(...) is a piped
> |output stream. After writing data to the output stream, calling
> |close does not directly acknowledge all of the data has been
> |written to the remote side. In the code I was writing, this
> |caused a timing hole whereby the next step in the test was
> |executed but the full set of data hadn't actually been written
>I have not tried it yet, but how about calling flush() method of that
>given OutputStream? Does it do the trick?