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.
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.
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?!
try to use pidfile as lock and process single like kill 9 as communication tool
Related
So, say I have multiple instances of a java program running, and I need to get information from each instance, ie if the program is performing its function correctly and if its not I need to get information to the process on what to do, I essentially need to open a tunnel. How would I do so? I hope this question isn't to vague.
I'm basically writing a manager, the manager loads a bunch of clients and I need a way to communicate between the manager and each client.
Have you looked into Java Management Extensions? It's built-in and made for monitoring java processes:
http://openjdk.java.net/groups/jmx/
if you need to look at custom info for your processes (some state of execution, or some special log info), you can create your own info-providers (aka "MBeans"):
https://blogs.oracle.com/WebLogicServer/entry/developing_custom_mbeans_to_ma
hope that helps
I'm having two main code design problems in my app.
My app mainly consists in sending ssh commands to a remote host.
Right now I have a separated thread (singleton) which gets messages through the handler which specifies which is the next command to be sent, or the username/password/ip (kind of messy but works...).
This approach works good for unidirectional commands, but I'm planning to make it bidirectional which I don't know how to implement. As far as I know Android doesn't allow to change UI elements by another thread so a listener pattern wouldn't be it.
Also, I just read that we shouldn't save things in the application object, which is also what I'm doing by saving whether my app is running full or lite mode... I don't know where should I save it in order to not make it obviously hackable (sqlite-SharedPrefs are easily editable...)
Only a general hint: There is Activity.runOnUiThread() to execute code (later) on main thread.
I need to call some Unix commands from my Servlet.
I have some Perl script, but I want to "translate" them into Java.
Here is something that I want to do on Java, but that I've made in Perl:
system("myfolder/myscript.sh > /myfolder/logs/myscript.log");
Is it possible to do this on a Servlet?
Yes, but note that redirect is part of the shell you will want:
ProcessBuilder pb =
new ProcessBuilder("/bin/sh", "-c", "myfolder/myscript.sh > /myfolder/logs/myscript.log");
pb.start();
Short answer:
it's possible but it's bad design, and can pose a security risk.
better to flag somehow that the script needs to run and check the flag via script
Long answer (following the commments):
Servlets are usually used to provide a user interface (or api) to something, for example accessing data or in your case triggering an action. As such, they imply the possibility of access from a remote resource such as a remote computer. In some (actually most) cases, that remote computer may even be out of the network, for example somebody's home.
Every server which is exposed to the outside world has the potential of being hacked or attacked in some way, with the risk being directly related to the level of interest this resource poses.
For example, if you work for a big company (which is then noticeable by hackers), and this servlet is used to trigger a build in your local repository, and you decide that developers will be able to work from home and need to login in order to trigger a build or check their build status, it means that anyone with the right credentials can potentially access the servlet, from anywhere in the world. Now lets assume that your perl script needs to access your CI server for some data, and your source repository for another data (maybe it even copies the sources instead of letting the CI server do it). In this case, you just created a direct link between someone sitting somewhere in the world, to the company's source code. It also means that even if it's too hard to penetrate your incredibly secure service because you spent a vast amount of time closing all potential gaps, they may still be able to trigger many unnecessary builds, and if you work in Continuous Deployment even make those builds go to production (maybe causing a DOS attack or service disruption). If at some point someone decides that the script also needs to get a parameter from the servlet, you've even made the hacker's life easier and could eventually give him access to your system.
All I described in the previous paragraph may be completely irrelevant to your case, you might be developing a service which will run on your home computer and won't interest anyone but yourself, but this does not change the fact that this is bad design (which might be ok for home use by the way).
What I said in the short answer is that it's better to have servlets flag the system that an action is needed, for example set a flag in DB or even in a file, in this case a hacker's life would be much more difficult, as there's no direct link. This also makes the servlet respond immediately, possibly automatically updating on status, instead of waiting for the perl script to finish running.
Did u try Jsch.It can do ssh and execute shell commands.
I am currently following an article about a simple gameloop, I can get my game going locally and I can add a lot of objects and behavior into it.
The article is this: http://www3.ntu.edu.sg/home/ehchua/programming/java/J8d_Game_Framework.html
My game is a grid, where other players can change some simple rectangles. It doesn't need to be the fastest approach, but somehow I need a new thread that connects to my server, and modifies the gamestate, which will get drawn on the screen. I just can't see how I can implement it, without causing the applet-thread to hang.
Can somebody see a solution to this?
Are you having a threading problem, or are you asking how to design the communication between the server and client?
For the communication problem, here's a simple approach: have the server periodically send each player updates, whether through a constantly connected TCP connection or just periodic plain old unreliable UDP packets. The choice of which one to use will depend on your application requirements. Read about the difference between TCP and UDP -- there are many, many places,including on SO (just search), that discuss the tradeoffs. Once you have the server updating on state and you can verify this works by giving the server some scripted state to follow, you can send some data the other way too. Depending on your application, you may need to be careful about security: whether a player can lie to the server about its actions, etc.
In Java, connections are often done through the Socket and ServerSocket classes, or through the DatagramPacket and DatagramSocket classes.
I just can't see how I can implement it, without causing the applet-thread to hang.
Implement an ActionListener to do the server update/check. Call the listener in a loop using a Swing Timer. See How to Use Swing Timers for more details.
I have a java application where I want to check to see if an application is running. If it is not running, I want to start it. If it is running, I want to kill it and then restart it.
Can someone tell me how to do this? I can start/stop the program easily enough, with the ProcessBuilder. But I cannot detect a process that is already running.
Thanks for your help!
John
Without the cooperation of the application (ideally have it listening on a network port), that may be impossible (your Java app might not have the rights to kill the app) and requires OS-specific code. On Linux, you'd uase the ps and kill commands.
Might sound silly, but you can create a file with a known name on application startup. Doesn't need to contain anything. To check if your application is running, check if that file exists.
Is the other application (the process you are monitoring) under your responsibility? If so, you can use a method I used in some high-availability system a few years back:
Open a connection to that other application and "ping" it. If the other application does not respond within a given timeout, it is either down or "hung", which is as bad (and something you can't detect through process monitoring.
Opening a connection can be done using sockets, or though more sophisticated protocols (SOAP?).
An alternative is to have the application send a "I'm alive" message every so often. If you haven't received it in some time - your application needs restarting.
In order to actually "kill" the other process, you can keep the Process instance you get from the exec() method, and destroy() it when you so choose.
Thanks for the replies. That was what I was afraid off. We are trying NOT to add more things to the application that I want to start up. We are basically trying to add a remote control web interface to a collection of applications.
The web server application that I am writing would basically start/stop 3 apps that all talk to each other to achieve a goal. If my web server starts and stops them, all is well. But if, for some reason they are already running when I try to start them bad things happen.
It is something I know I could handle with Visual Studio (C++/C#/etc). But this project has to be written in java due to a platform independence requirement.
Thanks for your help everyone!