4

So I am making a program that will only run one instance at a time and am doing so by using this solution

However now I would like to make it so that if the user trys to launch another instance it will consume that attempt and notify the current instance to show its gui.

Currently I am thinking about doing this by the use of a file. Upon the launching of a second instance, a file called show.stage will be created. When the other instance detects that file it will show its gui and delete the file.

I know this works but I was wondering if there was a more graceful way to do this.

Could I some how set a environment flag that the other instance could check for or maybe notify it via a socket listener, although those seem to be discouraged by others. I get the feeling creating the file will be the easiest and most robust way but I am open to any suggestions

This program will be running on normal windows.

Austin
  • 726
  • 4
  • 22
  • 2
    Your file is probably the easiest way to go. The file probably wants to contain connect info for the client who finds the file there to know how to contact the instance that created the file. – moilejter Aug 11 '18 at 18:15

3 Answers3

1

If you don't want to use a lock file (which I think is a perfectly good solution), you can use sockets.

Have your application create a socket server and listen at some port in localhost. If it fails to listen, it would mean that someone else is listening to that port already - most likely, another instance of your app. You can even connect to that port and send messages to notify the primary instance that a second instance tried to be spawned.

The caveat is that if another app legitimately uses that port your app would never be able to run - but I find that very unlikely to happen.

JVon
  • 684
  • 4
  • 10
1

There are many ways to go about this:

  • as you already figured, the file system can be used as communication channel between two jvms. But that only works for jvms running on the same server.
  • thus the already suggested socket solution enables you to (later) apply the same solution to a distributed environment. The downside is that you have to implement a protocol on a very low level.
  • in the past, people often turned to message bus solutions (think ActiveMQ for example)
  • in 2018, the other alternative would be to implement a simple restful API, using jaxrs and jersey for example.

As said: the effort you want to put into this depends on your requirements. How long will it be used? What are the odds that your solution will grow and has to scale to more than one server?!

GhostCat
  • 137,827
  • 25
  • 176
  • 248
  • 1
    Sorry I didn't clarify earlier but this isn't a server program, although you did bring up some interesting ideas for another one of my projects. – Austin Aug 11 '18 at 19:25
  • You are welcome. You know, in case you don't accept answers, you can always upvote to show your appreciation :-)... And rest assured: restful sounds like a lot of work, but using jersey and gson you can pull together pretty amazing stuff within a few hours. – GhostCat Aug 11 '18 at 19:26
-1

try to use pidfile as lock and process single like kill 9 as communication tool

宏杰李
  • 11,820
  • 2
  • 28
  • 35