Kabir Khan wrote:
Brian Stansberry wrote:
I agree it makes more sense to handle a failure of 1) by using the PM to tell the server(s) to reconnect. Stopping and starting the SM's listening socket gives me a bit of a queasy feeling though; it could interrupt other on-going communication. Is the advantage mainly simplicity (stop and start the socket triggers the existing 6.3.4 logic above instead of requiring the SM to send a command to the PM)?
I suggested restarting the listener for two reasons. It sounded simpler, and I am not sure in what situations the SM listener would be well and truly broken. But I can definitely send a command to PM instead (and then if we find scenarios where we need to restart SM's listener I'll deal with those later).
Sounds good.
The PM needs to consume each process' stdout and stderr anyway.
Not sure what you mean here? We still consume stderr for logging but I have done away with the stdout consumption. If you mean for monitoring whether the process is still alive, that is now done by a simple Process.waitFor().
A key thing the PM needs to do is handle the last sentence in this bit from the java.lang.Process class javadoc:
"The created subprocess does not have its own terminal or console. All its standard io (i.e. stdin, stdout, stderr) operations will be redirected to the parent process through three streams (getOutputStream(), getInputStream(), getErrorStream()). The parent process uses these streams to feed input to and get output from the subprocess. Because some native platforms only provide limited buffer size for standard input and output streams, failure to promptly write the input stream or read the output stream of the subprocess may cause the subprocess to block, and even deadlock."
So, whatever comes out of stdout or stderr needs to be consumed promptly.
Using stdin all the time for PM -> Process sounds good.