Communication between multiple JVMs
We have a Java toolkit that is shipped as a JAR file. The toolkit is ported from a C++ DLL running on Windows. Therefore, in both instances (Java and C++), we can't control who loads us or when.
I need to communicate between different JVMs running on the same machine. The communication is very simple: "Is this user logged on in your JVM?" I send a string to the other JVM and I get back a boolean. I don't need to worry about crossing machine boundaries. Also, I'm not expecting to have a huge number of JVMs running. Maybe 3 or 4 could be likely. However, the solution does need to scale in case there are more than that. I'm not setting a limit on the number of JVMs either.
The C++ code handled this situation very easily and elegantly. It created a named system semaphore (mutex) whenever a user logged on. The name of the mutex was the username. So, if there were multiple instances of the DLL running in separate processes (EXEs), we could easily tell if this user was logged on in another instance. We'd try to create the system semaphore - it would fail saying the name already exists. Therefore, we'd know the user was already logged on. The named system semaphore provided the means for a machine-global list - which is exactly what we wanted. It also had this extra benefit: if the process terminates normally or abnormally, the system semaphore is removed from memory. This means: the application is terminated, the user is no longer logged on, and we can relog this user on.
Therefore, I have 2 requirements:
1) A machine-global list where we can place a string. Keep in mind, it doesn't absolutely have to be a machine-global list. A suitable means to talk to other JVMs is acceptable too.
2) If the process exits normally or abnormally, the string(s) get removed (for this JVM) from the list. Abnormal termination is the more important one to focus on because lots of people of varying skill levels use our toolkit. Abnormal terminations can be common.
The first thought is to store these in a file. That solves #1, but not #2. I've seen the JIPC package. However, I'm not too crazy about requiring 3rd party developers to start up another program (JIPC) before they start up their application. As I said, we're just a toolkit so we can't control when or who loads us. It's not totally out of the question, but I'd prefer something else.
I have a fairly involved solution that involves sockets. The first JVM creates a ServerSocket on a specific port and becomes the server. Subsequent JVMs also try to create the ServerSocket on the same port. They get a BindException because the ServerSocket already exists, so they know they're clients. Then, they create a client socket and talk to the server that way. This gets a little hairy when the server goes away. The clients will scramble to become the server and then all the other clients need to reconnect to the new server.
This proposed solution sounds like it will address both requirements. However, I'm looking for something simpler. I'm asking this forum for help in case there's an easier way to do this. I don't have the breadth of experience with Java yet to know if there's a simpler way to fix this. If I have to go with the socket solution, I will. I just didn't want to overlook something simple that is already built into Java.
Thanks for any tips or suggestions
