P4
Suppose rmid crashes (say, OutOfMemoryError) and gets restarted by some system mechanism. Further suppose an activatable server that was running when rmid crashed, and that is auto-started on rmid startup.
As things stand there will be two instances of the server running. This can cause big problems, for example if the server implementation modifies a persistent store with the assumption that it is the only running instance (a reasonable but naive assumption). A server can be written to detect this situation but it is complex and has some interesting race conditions that people are likely to get wrong.
rmid should remember what it started up last time and either ensure that it gets shut down when a second rmid starts up or adopt the existing server if it is still present. The second form is in some sense preferable, since it means that startup overhead would be minimized, but it may be problematic.
One strategy would be for rmid to keep a port/group list in its persistent store. When rmid was shut down cleanly it would clear this list. When rmid boots it would check the list and contact the activation system at that port to see if it is still managing the group. If it is, one of two things can happen. rmid could tell the activation system to invoke System.exit or it could adopt the process at that location. If it adopts the process it will need some way to destroy that process in the future, which presumably would also be sending a message that caused it to invoke System.exit. Clearly the "invoke System.exit" command should be protected in some way to prevent malicious people from sending the message to arbitrary activatable servers in the network.
As things stand there will be two instances of the server running. This can cause big problems, for example if the server implementation modifies a persistent store with the assumption that it is the only running instance (a reasonable but naive assumption). A server can be written to detect this situation but it is complex and has some interesting race conditions that people are likely to get wrong.
rmid should remember what it started up last time and either ensure that it gets shut down when a second rmid starts up or adopt the existing server if it is still present. The second form is in some sense preferable, since it means that startup overhead would be minimized, but it may be problematic.
One strategy would be for rmid to keep a port/group list in its persistent store. When rmid was shut down cleanly it would clear this list. When rmid boots it would check the list and contact the activation system at that port to see if it is still managing the group. If it is, one of two things can happen. rmid could tell the activation system to invoke System.exit or it could adopt the process at that location. If it adopts the process it will need some way to destroy that process in the future, which presumably would also be sending a message that caused it to invoke System.exit. Clearly the "invoke System.exit" command should be protected in some way to prevent malicious people from sending the message to arbitrary activatable servers in the network.