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).
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().
I don't think it's good though to try and route commands over stdio besides the ones needed to get the socket communication going away. Otherwise we face the problem of dealing with junk sent via stdout that led to our using sockets. One thing though is the PM can safely use each child process' stdin to send commands to that process.
I agree. To keep things simple:
a) PM will only listen for input from processes via the process sockets
b) PM will only send data to processes via stdin
If the socket goes down PM will send a message to the process via its stdin to reconnect to its socket. For b) I am currently using the socket to push commands from PM->Process and was going to switch over to stdin when the socket goes down, but it will be a lot simpler, with less switching between different communication mechanisms, if we just use stdin all the time.