Thread restart after computer standby - java

I have an application running in the Windows system tray and it seem like after I put the computer in stand-by (not shutdown!) when I turn the system back on, a Thread I have running in the application does not continue running. How would I either A) keep the Thread running, or B) determine the system has come back from stand-by and restart the Thread?

You don't need to resume threads after the system resumes. That happens automatically. If your thread or process doesn't resume operation properly it is probably mis-handling the standby or hibernate.

Maybe the application is not 100% thread-safe and/or the thread died by an uncaught exception while the system is going stand-by or back from it. Set up an UncaughtExceptionHandler for your thread which logs the uncaught exceptions to a file.
FindBugs and PMD are also useful for hints.

Related

Command to Interrupt a hung thread running in a java process without code changes

I've a java process running and unfortunately one thread inside the process is hung.
I found the Thread id which was hung using jstack, however I was unable to find any references on how to interrupt this thread using the id?
Is it possible to Interrupt/Stop a thread from console (or basically outside the process) by using the processId and ThreadId?
Any suggestions on how to tackle this?
PS : I don't want to kill the process as its just one thread which is hung. Also, neither do I want to make code changes to Stop/Interrupt the thread. I just want to kill it, so all its resources can be released.
There's no baked-in way to kill a thread within the JVM, at least not a deliberately implemented one.
Having said that, if you have started your JVM with the appropriate parameters, so that you can start a remote JMX session to it, you can actually suspend the thread and inject a RuntimeException into it, which will almost surely terminate it (unless you are doing something gnarly with RuntimeExceptions in it).
See this blogpost.
P.S. You would never start your JVM in production allowing rogue JMX connections though, and if you're not in production, I'd guess that the above approach is not of much help to you.

Whenever my program crashes in eclipse it stays running in the background

It is really frustrating especially when I am working with sockets. Anyone know how to fix this? I constantly go into the task manager...
I think the most likely reason for this is a thread which does not terminate. This might be caused by the thread waiting for a time out, but a number of other reasons might prevent the thread from exiting as well.
I suggest you connect jvisualvm (part of the jdk, located in the bin folder) to your application and investigate what part of your application stays alive.
Edit: If your application runs in your systems default vm, you should see it in jvisualvm out of the box. But if you are using different vms, you have to start the application with appropriate parameters in order to connect jvisualvm to it.
This short guide explains the settings pretty well.

Daemon Thread is still alive after closing the app

I'm just testing with an almost empty android project.
I created a daemon thread in the Main Activity.
Started the app, and pressed the back button on the phone to close the app.
But the daemon thread never dies.
Daemon Thread works really well with an empty JAVA PROJECT.
But with android, doesn't work.
I searched for the solution for hours but only got this.
A daemon thread only runs as long as there are non-daemon threads
running. When the last non-daemon thread ends, the runtime will exit.
This is not normally relevant to applications with a UI.
Does anyone know how to solve this?
PS.
I stopped the app not by pressing the hardware back button but by pressing the 'Force stop' button in 'App info', and both of the app and the thread are gone!
I first learned about Daemon Thread from some example codes for android develoment.
But nobody mentioned about what I've experienced.
Do android developers just believe Daemon Threads will be killed for sure?
But the daemon thread never dies.
Presumably, you did not cancel() the thread. You need to do this at an appropriate point.
But with android, doesn't work.
It works just fine. It works the same as in Java, as you can tell by reading your quoted passage. The difference is in how long your process lives and in the threads in that process (Android processes have other threads besides ones that you fork).
Does anyone know how to solve this?
Call cancel() on your thread at an appropriate point.
Pressing back button does not close the app (assuming that closing means process termination). That only finishes an activity but process is still running.
To achieve desired behavior you can use eg. AsyncTask and call cancel() from appropriate callback of your Activity eg. in onDestroy() or onBackPressed() if you are interested exactly in back button presses.
apologies for pointing possible basic out but follow your problem have you ensured after closing that its not running in you Task Manager (ctrl+alt+delete)..have task manager running alongside your daemon then during the closing of daemon watch what happens during and after closing in task manager as it may be backing up files in accordance with settings-check settings in daemon....or have you used an ExecutorService to run as Daemon in Java in which case this will prevent your program from shutting down see here
ExecutorService - 10 tips and tricks
Java Applicatioin Process Hangs on Windows and Cached Thread Pool

Proper shutdown of JVM when launching from C++

I'm launching JVM from C++ code via JNI. I have a problem that when just quitting my C++ process it seems some shutdown hooks from JVM are not run, and therefore some temp resources are still being around, that in my particular case prevents launching JVM next time I open a C++ process.
I tried jvm->DestroyJavaVM(), but after all my process windows were closed, I still could see the process running. What's the best wait to ensure that the JVM is shut down properly when launched via JNI?
Thanks!
First of all, jvm->DestroyJavaVM() won't return till all non-daemon jvm threads have stopped, it does nothing but waiting for them to stop, so you should stop them in java.
Secondly, System.exit will cause the whole process to be shut down.
So what you really need is check your java code that which thread is not stopped yet, for example the background message loop thread of the ui framework such as gwt or swing.
The easiest way is to call System.exit via JNI.

Should threads have special design to be shutdown gracefully by Tomcat?

I have developed a multithreaded web application that runs in Tomcat.
But I cannot use
shutdown.bat
Tomcat didn't stop gracefully. In the debugger I saw that threads continue to run after shutdown command. Do I have to fix my application code to meet special requirements ?
Thanks.
... and to tie the other responses to the workings of Java Servlet environments;
if you don't declare your threads as daemon threads, the way to signal the server shutdown to the threads is to implement a ServletContextListener and configure it to your web application (web.xml). When Tomcat is shutting down, it will first shut down each application, which in turn will cause contextDestroyed() method of the listener to be called - and this is where you can signal your own threads that they should finish their work.
Any threads that are still running will keep the Java (Tomcat) process alive. Make sure all your threads exit. Once your threads exit, Tomcat will be able to shut down.
See the javadoc for Thread. Note the following:
The Java Virtual Machine continues to execute threads until either of the following occurs:
The exit method of class Runtime has been called and the security manager has permitted the exit operation to take place.
All threads that are not daemon threads have died, either by returning from the call to the run method or by throwing an exception that propagates beyond the run method.
You need to cancel your threads, preferably by calling interrupt on them and making sure they are written in such a way that they respond to the interruption -- meaning, checking their interrupted flag and responding intelligently to InterruptedExceptions (not just eating them and continuing on).
The above advice assumes you don't want your threads to drop what they're doing immediately. If you are ok with that then make them daemons.

Categories

Resources