> 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