Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / January 2007

Tip: Looking for answers? Try searching our database.

Preventing multiple instances of an application to start

Thread view: 
Philipp - 04 Jan 2007 08:05 GMT
Hello, I had the problem that I did not want multiple instances of my
application to start. I would like instead to have the command line
parameters (file paths in my case) of a second starting instance to be
forwarded to the first already running app (eg. if someone double-clicks
on an associated file type).
Here is the solution I came up with (posting it for future reference).
Any comments/corrections are welcome (this is my first try at RMI).

Phil

-- RemoteContactInterface.java --
import java.io.File;
import java.rmi.Remote;
import java.rmi.RemoteException;
public interface RemoteContactInterface extends Remote {
 void loadFile(File f) throws RemoteException;
}

-- MyMainClass.java --
import java.io.File;
import java.rmi.RemoteException;
import java.rmi.registry.LocateRegistry;
import java.rmi.registry.Registry;
import java.rmi.server.UnicastRemoteObject;
import javax.swing.JFrame;
import javax.swing.JLabel;
import javax.swing.SwingUtilities;

public class MyMainClass extends JFrame implements RemoteContactInterface {

 MyMainClass(){
//  start RMI server
  try {
   int PORT = 1099;
   LocateRegistry.createRegistry(PORT);
   RemoteContactInterface stub =
(RemoteContactInterface)UnicastRemoteObject.exportObject(this, PORT);
   Registry registry = LocateRegistry.getRegistry();
   registry.bind("myClassID", stub);
   System.out.println("Server ready");
  } catch (Exception e) {
   System.err.println("RMI Server exception: " + e.toString());
   e.printStackTrace();
  }

  setDefaultCloseOperation(EXIT_ON_CLOSE);
  this.getContentPane().add(new JLabel("Hello World"));
  pack();
  setVisible(true);

 }

 public static void main(String args[]) {
  try {
   Registry registry = LocateRegistry.getRegistry(null);
   RemoteContactInterface stub = (RemoteContactInterface)
registry.lookup("myClassID");
   for(String s: args){
    File f = new File(s);
    stub.loadFile(f);
   }
   System.out.println("App already running");
   System.exit(0);
  } catch (Exception e) {
   // if exception is thrown, no other process already exists
   // go on with normal loading
  }

  SwingUtilities.invokeLater(new Runnable() {
   public void run() {
    MyMainClass myClass = new MyMainClass();
   }
  });

 }

 public void loadFile(File f) throws RemoteException {
  // load the file here;
 }
}
Andrew Thompson - 04 Jan 2007 10:00 GMT
> Hello, I had the problem that I did not want multiple instances of my
> application to start. I would like instead to have the command line
> parameters (file paths in my case) of a second starting instance to be
> forwarded to the first already running app (eg. if someone double-clicks
> on an associated file type).

Note that web-started* applications can make use of the
SingleInstanceService to avoid furrther instances.

* ..and will also offer support for file associations.

Andrew T.
Philipp - 04 Jan 2007 10:48 GMT
>> Hello, I had the problem that I did not want multiple instances of my
>> application to start. I would like instead to have the command line
[quoted text clipped - 4 lines]
> Note that web-started* applications can make use of the
> SingleInstanceService to avoid furrther instances.

Hmm... You mean I should have read the doc? :-)
Andrew Thompson - 04 Jan 2007 10:51 GMT
> >> Hello, I had the problem that I did not want multiple instances of my
> >> application to start. I would like instead to have the command line
[quoted text clipped - 6 lines]
>
> Hmm... You mean I should have read the doc? :-)

10% yes/90% "might this app. be suited to launch
using web-start?" (not all projects are suited to
web-start install/launch.)

Andrew T.
Tor Iver Wilhelmsen - 04 Jan 2007 16:13 GMT
> 10% yes/90% "might this app. be suited to launch
> using web-start?" (not all projects are suited to
> web-start install/launch.)

A common trick is to try and open some serversocket on a particular
unlikely-to-be-used port number, (like 11544) and failing if it cannot
(because another running instance has done so).

Another trick is to write a ".lock" or ".pid" file to the file system
and test for its existence, remembering to remove it at the end. This
is less relibable than the first because the app can crash wothout
being able to remove the file, so the user has to hunt for it.
Andrew Thompson - 04 Jan 2007 16:33 GMT
(single instance of application)

> > ..launch using web-start..

> A common trick is to try and open some serversocket on a particular
> unlikely-to-be-used port number ..
...
> Another trick is to write a ".lock" or ".pid" file to the file system
> and test for its existence, remembering to remove it at the end. This
> is less relibable than the first because the app can crash wothout
> being able to remove the file, so the user has to hunt for it.

Yes.  I would far prefer to use the first strategy,
probably also allowing the user to set the port
number (to cover possible clashes).

(Assuming I could not simply rely on JWS to
do it for me - to be honest - I have never really
needed to code a SIA, so for my part, it is all
theoretical.)

Andrew T.
Tom Hawtin - 04 Jan 2007 16:43 GMT
> Another trick is to write a ".lock" or ".pid" file to the file system
> and test for its existence, remembering to remove it at the end. This
> is less relibable than the first because the app can crash wothout
> being able to remove the file, so the user has to hunt for it.

Isn't the idea to put the process id in the file. Then if the file
exists, the new process to check whether the process that created the
file still exists. Still very hacky, but slightly more reliable.

Tom Hawtin
Philipp - 04 Jan 2007 17:05 GMT
>> 10% yes/90% "might this app. be suited to launch
>> using web-start?" (not all projects are suited to
[quoted text clipped - 8 lines]
> is less relibable than the first because the app can crash wothout
> being able to remove the file, so the user has to hunt for it.

I read about these two methods. But aren't they much more ugly than
using RMI which is precisely tailored to speak to other running apps?

Also, is it possible to pass new arguments using these methods? (I don't
think so).

I'm surprised that the two methods you cite are written all over the
web, but the RMI method is nowhere to be found. Is there anything wrong
with it?

Phil
Chris Uppal - 06 Jan 2007 15:49 GMT
> I'm surprised that the two methods you cite are written all over the
> web, but the RMI method is nowhere to be found. Is there anything wrong
> with it?

In essence the RMI-based approach is the same as the socket-based one.

There are minor differences of course. The RMI one makes it easier to extend to
passing data across to the previous running instance.  The RMI one is probably
easier to code if you are used to RMI, but harder to code if you are used to
sockets. The sockets based one may use rather fewer OS resources.  It might be
a bit easier to control security with raw sockets.  And so on...

My personal feeling (I know socket programming but have never really used RMI)
is that the RMI solution is somehow too heavyweight (taking a hammer to crack a
nut) unless you are going to make use of the "RMI-ness", but that could just be
prejudice.

   -- chris


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.