My program is fairly large, and because it tends to carry out processes randomly, at times it gets stuck and loops forever. If I were to forcefully stop and restart the program manually, usually (around 85%) of the time, the program completes all commands and terminates.
Is there a way to make a Java program restart itself after say 20 seconds, if it gets stuck? I tried using the system time to solve the issue, but the problem with this is that if my program gets stuck in a for loop, it does not update the system time until the next iteration.
This isn't the right way to approach this problem! You need to figure out why your program is getting stuck in an infinite loop, and then fix it. "Okay let's try this again" is not the right way to solve a bug - you have no idea what other effects this bug could be having. You might very well be getting incorrect output as well. Debug the program, don't work around the flaw.
You could use some external program that launches the java program and kills it after 20 seconds when it gets stuck, and then launches it again, but again, that is not the right way to solve the problem.
Considering that solving this problem would mean solving the Halting problem, we can be fairly sure that the whole approach is doomed ;)
You could obviously use timers to kill the program after some specified time and whatnot, but really - find the bugs in your program.
Your program shouldn't stuck and loops forever, repair this. But if this isn't possible and you still want "restart" program after forever-loop I propose you such solution:
Create main program which will be director. The director will be create thread. The thread will be doing main algorithm which can take a lot of time. The director will be waiting some time which will be final parameter. This parameter help to director recognises if the thread is in forever loop (it takes too long time). When forever-loop will be recognize, it'll terminate the thread and start new one (restart).
Have a look at ExecutorServices to get a mechanism that allows you to invoke a piece of code and receive a timeout if it doesn't finish within the expected time. You can then act upon as you see fit.
Another nice tool is to use jvisualvm in the JDK to attach to the program when looping. You can then ask for a thread dump and use it to figure out what it is doing.
Related
I'm working on creating a batch simulation process for which I'd like to run a simulation and once it is complete, have it close itself. I see there are functions for pausing, finishing, and stopping a simulation run, but haven't found one to close the entire program execution. Does that exist, and if so, what is it?
The highest level of control in anylogic is called an experiment. To close that use close(). This will immediately stop the experiment, destroy it and close the windows. Source
Experiments may have multiple runs of a simulation. To stop a simulation you can use getEngine().finish() to soft stop it, and getEngine().stop() to hard stop it. Source
I have a JavaFX 8 app that is occasionally hanging/freezing. I feel I've ruled out many causes of the problem, but it's still happening.
Unfortunately I cannot reproduce the freeze/hang on demand. It actually only happens (so far) on my colleague's computer. It can happen not long after the App has been running, or it may happen after many hours, or it may not happen at all. It does not happen after any user initiated event (such as pressing a button).
I have a few background threads running that read data from sockets and update the JavaFX UI. These updates are always done via the Platform.runLater() method.
The background threads may read many hundreds of data updates per second, so I have applied throttling to prevent too many updates on the UI, as suggested here: Throttling javafx gui updates
The user can initiate some long(ish) tasks, which are run on the JavaFX UI thread, or using the Task method. I know and expect the JavaFX UI to block/freeze when calling a method with long execution time on the JavaFX UI thread. But such calls are only made by the user pressing a button and as stated above, the freeze occurs without the user interacting the the App in any way.
I have caught the freezing (twice) on my colleagues computer and inspected the process in JConsole and VisualVM. The thread dump showed no deadlocks. When I compare the thread dump with a non-frozen JavaFX App thread dump, there are no obvious differences.
It appears that only the JavaFX UI is frozen. The background threads continue without error.
The CPU is not high and the computer is not running slow when the freeze occurs.
My App code consists of many classes, so it's not straight forward to include it here, especially as I don't know which method causes to freeze. And therefore my question is rather broader than I would like:
Given the assertions above, do you have any suggestions as to what
might be a cause of such an error?
Given the assertions above, do
you have any suggestions as to what might be another way to trace
such an error?
Thanks to John16384 and Mipa for their replies...
I use the javafx-maven-plugin Maven plugin, so the JavaVM arguments by including:
<jvmArgs>
<jvmArg>-Dprism.verbose=true</jvmArg>
<jvmArg>-Dprism.order=sw</jvmArg>
</jvmArgs>
in my plugin configuration. Since including this, we haven't had the freeze for a couple of days. I'm hoping this is the final fix!
Have you tried AOP ?
Aspect Orientated programming
It in your case would allow you to run a method before and after every method you use, if you logged something if these times were greater than a certain time, then you could determine which bit of code was causing it e.g. log if the time inside a method is greater than 5 seconds
See here for a tutorial to just that
I ran a java program and calculated the time taken for a code to run. On multiple executions,I saw that the time taken keeps changing for the same piece of code. Could someone explain why? I used Eclipse IDE.
Note the times in consoles in below images
The jvm is working really hard for you dont put her on the clock!
also its nanoseconds not milliseconds, 459s would really be bad.
If you really want to mesure meaningful time do it on a scale where the background operations that grant you the privilege of coding without having to know what is happening on your machine and on which machine the code will be executed wont wheight as much. 1 second would be good enough
I recently ported a fairly large application from C# to Java. It ought to have about 6 main threads running and lots of timers being fired (but each executing only briefly). I make use of the Timer class and call myTimer.schedule(new TimerTask() { ...
Now that I'm at the end of the port, I'm having a problem debugging the application in Eclipse, especially lately. I set a breakpoint: Eclipse will hit it but I can't step through at that point. I don't think I can look at variable values or stack trace or anything.
I see my list of threads going crazy, and based on output statements I've written, I can see that Thread.activeCount() gets to be over 200 threads. I am curious as to whether this is my debugging problem. Have I overloaded Eclipse to the point that it goes crazy?
From the threads I can actually see, most of them are my Timers that have been run. Somewhere I read that the JVM will keep those alive even if you cancel them (?). Anyway, if it's including all of the timers I've fired then perhaps over 200 threads makes sense.
I did once today also see an Eclipse "out of memory" error.
Any advice? Thanks.
I am running a Java Program in command prompt
The normal course is after successfully executing the program it comes back to prompt .. what are the possible reasons it will not come back to prompt after successfully executing the program
why is it not coming back to prompt after execution
usually it comes back but sometimes it doesn't...
This sounds like a race condition. Something in your application's shutdown sequence is non-deterministic, and it works or does not work depending on various platform specific (and possibly external) factors. There is probably no point figuring out what those factors are (or might be), since it won't help you fix the problem.
Only difference is in RAM hard disk capacity mine is slower.. Can it be possible reason?
These could be factors, but they are not the cause of the problem. So focus on figuring out what makes your application non-deterministic.
As others have said, without more information (and relevant code) we can only guess.
When the application has failed to shut down, get it to give you a thread dump. Or try shutting it down while it is attached to a debugger. These may allow you to get some clues as to what is going wrong.
Finally, the brute force solution is simply to have the main method (or whatever) call System.exit(0) on its way out. But beware of the possibility of files not being flushed, etc if you do that.
Because it's not finishing. If it's sometimes happening and sometimes not, my instinct is that you have some sort of race condition. Probably one of your cleanup steps is hanging if another action has or hasn't been taken.
Without source code this will be hard to debug.
There could be an active thread still running which is not in "daemon" mode. For example, if you have a Swing GUI and all of the frames are closed the Event Dispatch thread is still active so the JVM will not exit.