I assume Java applications receive some sort of shutdown request when, for instance, an OS is trying to reboot. I would like to have some control over how my applications handle these requests. But, I do not know where to start. Some questions I have are:
Do all shutdown requests come from the JVM?
Are the requests different for containers, VMs, and bare metal OSs? I am especially interested on how this is handled inside a docker container.
And, of course, what libraries can I use to handle these requests?
It would be wonderful if someone could point to a resource where this is covered in depth, besides the raw documentation, such as a book or online course (does not have to be free). Although, a link to the documentation will definitely be appreciated as well. Thanks!
Update:
I know I need to be able handle an event like the power cord being yanked.
However, when I ask my Windows machine to shutdown, sometimes a window pops up saying something like "waiting for these application to close". So, I assume the OS tells the applications to shut themselves down before forcing them to stop. Is this an incorrect assumption?
What I want to accomplish is for the app to log information or update a database before shutdown.
I will take a look at the addShutdownHook. Thanks again!
You can add a shutdown hook via the Runtime class. Mind you, these are not guaranteed to run, such as if someone yanks the power cord.
Refer Oracle Documentation
I want run a background process at a specific time. I want that process to be run on the server even without running the application from End-User side. The application is made using Spring. Please suggest how to approach for it.
Thanks and regards
Souvik
I depends highly on what platform you are working on, and what you want to achieve.
If it is a simple application, that you simply want to invoke that on specific time, then you can use scheduling tools available on your platform, for example, crontab for Unix, or scheduled task (at) for Windows.
If you want the application to be run as a daemon process, and the application itself will handle the scheduling, then you need to solve two problem: 1. create a daemon process (aka system service), and 2. doing scheduling in Java.
For problem 1, there are already answer for it. Just have a search on Google on "Java System Service" will give you some other useful tools too, like Java Service Wrapper
For problem 2, there are a lot of way to perform scheduling in Java. You can do it by built-in Timer etc, or using scheduling library like Quartz
i want to create a applet which paints a running ball while a process a running in the Java application . I have no idea how to synch the process time with the applet life . Help please ??
Applets run in a browser controlled JVM, that is completely separate from the JVM executing your program, but can do anything a normal Java application can do.
Therefore the problem here is actually, how you can have one JVM ask another JVM for information and you have several options depending on your need and skills.
I would suggest you look into JMX which is usually used for these kind of things, and if inapplicable then the EndPoint class which provide a tiny web server to your application.
I'll try my best to explain the situation at hand. I'm developing an auto-logoff feature for an authentication application that runs in an embedded system and should work cooperatively with its own internal auto-logout system. First I'll briefly explain the native auto logoff. If I set it to 60 seconds and I'm in one of the system's screens, it will monitor and reset the timer upon user interaction. After being idle for 60 seconds, the system will call the Java authentication application and it logs off. This is easily done. Once an user logs in, the application starts a thread that just waits. When the application is brought back (upon timeout), a call for the notify() method is made, releasing the thread and executing the logout proccess. Relatively simple, right?
Now things get ugly. This embedded system supports multiple Java applications, as it is expected. But the system built-in auto logout will only keep track of things should the user be interacting with one of the system's native screens, if he's using another Java application, it will do nothing. So, in order to counter that, I need to come up with some way to implement an internal timer that works in conjunction with the workings described above.
In other words, should the system be in "Java mode" I need to use a coded timer, anything else I use the timer described in the first paragraph. The system itself doesn't help much, since there's no support to check in which state the machine is, so I'm pretty much left with only Java to do the job.
I've given it a lot of thought today but I'm just stuck. Any fresh ideas?
BTW, it supports only Java up to 1.4 so no advanced concurrency classes for me.
Edit: I forgot to mention that I can't just code a regular timer, since I can't capture native events from the system (I can capture events from other Java applications though) and a Java timer overrides the native timer function. That's why I need some "coordinate work" between them.
I want to reduce the CPU usage/ROM usage/RAM usage - generally, all system resources that my app uses - who doesn't? :)
For this reason I want to split the preferences window from the rest of the application,
and let the preferences window to run as independent program.
The preferences program should write to a Property file(not a problem at all) and to send a "update signal" to the main program - which means it should call the update method (that i wrote) that found in the Main class.
How can I call the update method in the Main program from the preferences program?
To put it another way, is a way to build preferences window that take system resources just when the window appears?
Is this approach - of separating programs and let them talk to each other (somehow) - the right approach for speeding up my programs?
What you're describing sounds like Premature Optimisation. If you're writing something other than a toy application, it's important to be confident that your optimisations are actually addressing a real problem. Is your program running slowly? If so, have you run it through a profiler or otherwise identified where the poor performance is happening?
If you have identified that what you want to do will address your performance issue, I suggest you look at running the components concurrently in different threads, not different processes. Then your components can avoid blocking each other, you will be able to take advantage of multi-core processors and you do not take on the complexity and performance overhead of inter-process communication over network sockets and the like.
You can communicate back and forth using sockets. Here's a tutorial of how to do something similar..
Unfortunately, I don't think this is going to help you minimize CPU usage, RAM, etc... If anything it might increase the CPU usage, RAM usage etc, because you need to run two JVM's instead of one. Unless you have some incredibly complicated preferences window, it is not likely taking that many resources that you need to worry about it. By adding the network communication, you are just adding more complexity without adding any benefit.
Edit:
If you have read the book Filthy Rich Clients, one of the main points of the book is that Rich Effects do not need to be resource intensive. Most of the book is devoted to showing how to add cool effects to an app with out taking a lot of resources. Throughout the book they are very careful to time everything to show what takes a long time and what doesn't. This is crucial when making your app less resource hungry. Write your app, see what feels slow, add timing code to those particular items that are slow, and speed up those particular parts of the code. Check with your timing code to see if it is actually faster. Rinse and repeat. Otherwise you are doing optimization that may not make any difference. Without timing your code you don't know if code needs to be sped up even if you've sped up the code after doing your optimizing.
Others have mentioned loading the properties window in a separate thread. It's important to remember that Swing has only one thread called the EDT that does all of the painting of pixels to the screen. Any code that causes pixels on the screen to change should be called from the EDT and thus should not be called from a separate thread. So, if you have something that may take a while to run (perhaps a web service call or some expensive computation), you would launch a separate thread off of the EDT, and when it finishes run code on the EDT to do the UI update. There are libraries such as SwingWorker to make this easier. If you are setting a dialog to be visible, this should not be on a separate thread, but it may make sense to build the data structures in a separate thread if it is time consuming to build these data structures.
Using Swing Worker is one of many valuable ideas in Filthy Rich Clients for making UI's feel more responsive. Using the ideas in this book I have taken some fairly resource intensive UI's and made them so the UI was hardly using any resources at all.
You could create a ServerSocket in the main window and have the preferences app connect to that with a regular Socket the protocol to use may be extremely simple, but... I think you should really look for the second approach: to build preferences window that take system resources just when it's appear?
To do that, you have to build the window and all it resources until the user performs the Preferences action, save your file ( or pass the content to the main app ) and dispose all the resources of the preference window by making all of its reference non accessible. The garbage collector will handle the rest.
Maybe you could use some sort of directory watcher like this or maybe implement some sort of semaphore.
Honestly, I think that you should be able to solve the problem if you have some sort of menu item that the user can access. Once that the user saves the preferences, these are written to a file. The application then loads the values from the file whenever it needs them.
If your system is operating slowly, or hanging, you might consider the use of threads, or increase the number of threads.
Actually, as others have explained, you can use socket for inter-process communication.
However, that won't reduce your overall CPU / RAM usage at all. (might even slightly worsen your resources usage)
For your case, you can launch the Perference window in a different Thread rather than a different Process.
Thread is lighter for OS to handle and poses no additional complexity for inter-process communications.
Nobody seems to have mentioned the DBUS - available to developers on a Linux system. I guess that's no good if you're trying to make a Windows/Cross Platform application, but the DBUS is a ready-made application-communication platform. It helps address issues such as:
Someone else might already be using the port you're trying. There's no way for you client application (The "Preferences" window I guess) to know whether the thing listening on that port is your main application, or just something else that happens to be there, so you'll have to do some sort of handshake, and implement a conflict-resolution mechanism
It's not going to be obvious to either the future you, or anyone who comes to maintain your app why you're on the port you are. This might not seem important, but communicating on Socket 5574 just doesn't seem as neat to me as communicating on channel org.yourorganisation.someapp .
Firewalls (as I think someone's already said) can be a little over-zealous
Also, it's worth getting your hand in on DBUS - it's useful for communicating with a whole bunch of other applications such as the little popup notification thing you'll find in recent Ubuntu distributions, or certain instant messaging clients, etc.
You can read up on what I'm talking about (and maybe correct me on some of the things I've said) here: http://www.freedesktop.org/wiki/Software/dbus . It looks like they're working on making it happen on Windows too, which is nice.