tomaswolf opened a new pull request, #256: URL: https://github.com/apache/mina-sshd/pull/256
Closing them when the channel closes leads to the strange situation that the application reads from an already closed InputStream. That's not a good idea. It's the caller's responsibility to close the input stream obtained from Channel.getInvertedOut() or getInvertedErr(). And of course it should do so only after it has read all the data it wanted, and the channel is closed. It's not a real problem if the stream is not closed (for instance, if the application never even called getInvertedOut() and never read anything). Closing doesn't do much anyway except awaking a potentially waiting read() call. Moreover, if the channel is short-lived and didn't transmit a lot of data, the application may well start reading from the stream only after the underlying SSH channel is already closed. One problem with this ChannelPipedInputStream is that it may buffer up to a full SSH channel window. If the window size is large, that may consume a lot of memory if the application only reads infrequently (or doesn't read at all). However, not reading from such a stream is bad practice anyway if there is any chance that there might be a substantial amount of data; as with processes, it may lead to a blocked execution when buffers fill up or the channel window is exhausted. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
