We Keep Coding

Let java program run indefinitely - restart when it crashes

I have a java program that should run on a Windows machine. It should run "forever", i.e. when the JVM or the program crashes, it should be restarted. When the computer is restarted it should also be restarted.
I saw advice to wrap the program as a "Windows service", but the tools I found seem to be either costly, complicated or outdated.
Can somebody describe me a straightforward way to achieve the desired behaviour?

For the part where you want to start the program after restart you can create a simple batch (.Bat) file and u can put that file in the startup folder.
Also you can use the same file for running the program when it crashes. you can use tasklist command and check if your java program is running and if it is not .just start the program.
Just check our windows batch this is one of the best things you can get everything for doing anything on windows without anything expensive

Yet Another Java Service Wrapper is a tool that easily wraps your Java program into a Windows service. Just start the program, note down the PID and enter it into the wrapper. Two things, which are probably universal to services, should be noted:
For connection to the network, you need to specify an account with the necessary rights.
Connected network drives are not available.

java not waiting for unix binary to complete execution

Im creating a javafx application to run a unix binary application, which limits the percent of cpu a process can use, herein i already have a cputhrottle unix binary which receives PID and CPU percentage as argument, my application just acts as a GUI for this unix binary.
When I run this cputhrottle from terminal it keeps on running, until i press - CTRL+C (this is the normal behavior).
But the problem is, when I run this unix binary with my java code, it seems, as if the program is almost immediately terminated (whereas it should be running, until I press the stop button), and because its not running & being terminated, My program cannot control the percentage of CPU a process gets.
Here's my code : http://pastebin.com/rbG3ctfH
so, is there a way to tell java to keep running the cputhrottle binary file, instead of closing it.
I've tried replacing the 56th line, and instead wrote code to execute a script, which would create a file, with some text content, & when executed he program, it did created a file, so its working, but when i add e1.printStackTrace in the catch block, it stops working for some reason.
And also, if I add sleep in the shell script, then its not executed Properly, more over no Exception is being Generated.

The command you are trying to run ("echo dkkdk|sudo....) is a shell command. You need to tell runtime.exec() to run 'bash -c echo dkkdk|sudo..'
Also be aware that runtime.exec is asynchronous and could/might/likely will return to your program before the child process completes.
Also, I could not pipe the superuser password to sudo like you are trying to do. Not saying it doesn't work for you just that I couldn't get my system to take it.

How do I stop a daemon thread that does scheduled database backup ?

I've written a very simple command line programme that uses mysqldump to dump data at a specified interval. I wanted it to be running after I run the programme and I disconnect putty ssh connection.
But as soon as I exit the ssh connection, the programme shuts down.
I think I can make my programme run even after I disconnected from the ssh by using daemon threads but I'm worried about not being able to find and stop unnecessary duplicate daemon threads.
The scenario I'm decribing is...
1. I log into the server using putty.
2. Turn on the auto backup programme.
3. I exit the putty connection.
---the daemon is running
4. Hopefully, when I log into the server again, I have a way to stop the auto backup programme if needed.
Cron jobs and DBMS specific methods are out of my options. I'd like to learn how to do the job described above and use it where ever the situation fits not just database backup.
Any good ideas ? : )

In short, you have to launch your program in a special way, and you have (at least) two options: nohup or screen.
Let's now discuss why and how each one works.
nohup
Java's daemon threads is not what you are looking for, they have nothing to do with the issue. You can use normal threads (or even a single-threaded java program). You just need to change the way you launch your java program.
I have many executable jars that run as "daemons" on a bunch of servers, and I made a simple launch script that prepares the environment and makes it possible to terminate the SSH connection without stopping it. The main part is how to invoke the JVM: you use nohup.
nohup java -jar myfile.jar > stdout.log &
From nohup's man,
nohup - run a command immune to hangups, with output to a non-tty
So, when you terminate your SSH connection, it will send SIGHUP to all processes it started which would terminate them as you are observing. With nohup, however, your process is immune to it.
Also, note that I redirect the standard output to a file called stdout.log. This is done so that you can see whatever your program writes to STDOUT (generally some logging information that would be useful for debugging).
To terminate your program, you can use jps to list the PID of your process (say it's 123), then call kill 123. Note that for this to work your program needs to correctly handle this kind of shutdown (which involves adding a shutdown hook with Runtime.getRuntime().addShutdownHook(...) which will terminate all the threads you launched).
If, for whatever reason (a bug, or you didn't implement a graceful shutdown), the program won't terminate after issuing the kill command (which sends the process a SIGTERM), you can change the signal it sends to SIGKILL with kill -9 123, which will simply destroy the process. Mind that this can be as dangerous as a power failure (ie, suppose you are in the middle of the try block of a try {} finally {} -- your finally block will not execute!).
screen
There's an alternative, which is to use SCREEN. With it, you launch a shell that is also immune to shutdowns, and that you can share among many connections. To use it, connect to your server, and then:
screen -R
A new shell will start, in which you run your java program as normal:
java -jar myfile.jar
To make it go to the background, just press ctrl+a ctrl+d. To bring it back to the front, just execute screen -R again. If you wish to terminate your program, you could do so by entering the screen session again and pressing ctrl+c (if your java program correctly deals with this kind of shutdown).

Two possibilities for scheduled tasks, in order from least to most complex, are the TimerTask and the Quartz Scheduler. Both offer the option to cancel/delete the scheduled job.

Problems with jetty crashing intermittently

I'm having problems with jetty crashing intermittently, I'm using Jetty 6.1.24.
I'm running a neo4j Spring MVC webapp, Jetty will stay running for approx 1 hour and then I have to restart Jetty. It is running on small amazon ec2 instance, debian with 1.7gb of RAM.
I start Jetty using java -Xmx900m -server -jar start.jar
I am connecting to the server using putty, when Jetty crashes the putty session disconnects, I cannot see what error caused it to crash.
I would like to be able to see if it is an error generated by Spring, I'm not sure how to log the output from the spring app with Jetty. Or if it is Jetty or a memory issue, what would be the best way to monitor Jetty? I cannot recreate this on my local machine running windows. What do you think would be the best way to approach this? Thanks

This isn't really a programmer question; perhaps it'll be moved over to ServerFault.
You didn't specifically state which operating system you're using, but I'm hazarding a guess at some Linux distribution. You have two options of figuring out what's wrong:
Start your session in screen. Screen will live for as long as the actual machine is powered on, until you reboot the operating system (or you exit screen).
you start screen like this
screen
and you get a new prompt where you can start your program (cd foo, jetty, etc). When you're happy and you just need to go somewhere, you can disconnect the screen by hitting CTRL+A and then CTRL+D. you'll drop back to the place you were before you invoked screen.
To get back to seeing the screen you type screen -R which means to resume an existing screen. you should see jetty again.
The nice thing is that if you lose connection (or you close putty by accident or whatever) then you can use screen -list to get a list of running screens, and then forcibly detach them -D and reattach them to the current putty -R, no harm done!
Use nohup. Nohup more or less detaches the process you're running from the console, so none of its output comes to the terminal. You start your program in the normal fashion, but you add the word nohup to your command.
For example:
nohup ls -l &
After ls -l is complete, your output is stored in nohup.out.

When you say crash do you mean the JVM segfaults and disappears? If that's the case I'd check and make sure you aren't exhausting the machine's available memory. Java on linux will crash when the system memory gets so low the JVM cannot allocate up to its maximum memory. For example, you've set the max JVM memory to 500MB of which it's using 250MB at the moment. However, the Linux OS only has 128MB available. This produces unstable results and the JVM will segfault.
On windows the JVM is more well behaved in this scenario and throws OutOfMemoryError when the system is running low on memory.
Validate how much system memory is available around the time of your crashes.
Verify if other processes on your box are eating up a lot of memory. Turn off anything that could be competing with the JVM.
Run jconsole and connect it to your JVM. That will tell you how memory is being used in your JVM process and give you a history to look back through when it does crash.
Eliminate any native code you might be loading into the JVM when doing this type of testing.
I believe Jetty has some native code to do high volume request processing. Make sure that's not being used. You want to isolate the crashes to Java and NOT some strange native lib. If you take out the native stuff and find it works then you have your answer as to what's causing it. If it continues to crash then it very well could be what I'm describing.
You can force the JVM to allocate all the memory at startup with -Xms900m that can make sure the JVM doesn't fight with other processes for memory. Once it has the full Xmx amount allocated it won't crash. Not a solution, but you can easily test it this way.

When you start java, redirect both outputs (stdout and stderr) to a file:
Using Bash:
java -Xmx900m -server -jar start.jar > stdout.txt 2> stderr.txt
After the crash, inspect those files.
If the crash is due to a signal (like SEGV=segmentation fault), there should be a file dump by the JVM at the location you've started java. For Sun VM (hotspot), it's something like hs_err_pid12121.log (here 12121 is the process ID).

Putty disconnecting STRONGLY hints that the server is running out of memory and starts shutting down processes left and right. It is probably your jetty instance growing too big.
The easiest thing to do now, is adding 1-2 Gb more swap space and do it again. Also note that you can use the jvisualvm to attach to the jetty instance to get runtime information directly.

i want to continously run my java threads

I am running my java application where i have used threads...
i am running this application using ant command on the terminal..
But when i close my terminal or press ctrl+c,then java program which was running stops...
Please help me out to solve this as i want to run this program continously...

If you kill the Java process, Java will no longer be running. If you want the threads to keep running continuously, the Java program must remain active.
Invoking such a program with ant is not usually the way to do it. On Unix-like systems, you would typically run such a program in the background via /etc/init.d startup scripts. In Windows the equivalent would be starting your program as a service, though I'm not sure of the intricacies involved in getting Java to run this way.
If you're running something from a concole - how about just not killing it and minimising the console? If you're starting it from Linux (or Cygwin) just append a & to the end of the command line and the process will run in the background.
Tell us more about your environment, and what compromises you're prepared to put up with (e.g. having a minimised console window sit in the taskbar) and we can help you more. At the moment, the only definitive answer I can give is that "yes - Ctrl-C will kill your program (as intended). If you want it to keep running, don't tell it to stop running." :-)

You can run your application as a service in linux or windows.

Have a look at the screen command for Linux.

I guess this is desired behavior. If you terminate your application, It gets shut down.
If you wish to run the application in the background you should consider making it a windows service or a deamon.
If you wish to continue running it as a application on *nix, you can consider to use GNU Screen.

Run the ant command in the background and redirect its output to a file:
ant &> my.log &.
NB: this issue does not seems thread related (unless I've misunderstood it).

It sounds like you want to daemonize your ant task. I'd suggest the following command:
nohup ant &> ant.log < /dev/null &
The nohup will allow the program to continue to run after you close the terminal.

I'm surprised nobody has mentioned the all-too-famous Java Service Wrapper. This is an excellent piece of software if you are developing long-running processes (a.k.a services).