If it is unix based, and since you put a sleep time that long, which equates to about 13.x hours between runtimes, you are better off just putting the app into the crontab.

Although you should clarify yourself. Your statement

"I placed thread.sleep(50000000), so the program will stay idle for 500000000 milliseconds before the next thread will fire up ... "

is quite vague. Are you saying that you have your main program thread spawn off a new thread, then go to sleep. And when it wakes up, spawns another thread and then goes to sleep? Or do you mean that you have a thread that runs, then sleeps for that amount of time, then wakes up again to perform a certain task, and then go back to sleep?

There are many good suggestions already in this thread...guess you can just follow one of them.. There should not be a big impact, although during coding and testing, I suggest you run with -verbose:gc to ensure that your program is not leaking (as a precaution).

Crontab dies half way? That's quite interesting. What kind of indications you have that showed that it died? In my previous company (one of the telco) we use Crontab to run scheduled jobs day in day out and it works very well. We have not had any failures which could be attributed to cron dying. Cron can sometimes be a pain to get right, although once it is, it works flawlessly..

AFAIK, windows task scheduler is a lot more unstable, which we have attributed it to some issues with the password setup etc. Just my 2 cents..

If a program is coded poorly, even with garbage collection, eventually you may run into an out of memory exception. Under certain situations as mentioned earlier for example, if you place something in a queue or list but forgot to clear it (common careless mistake) you may eventually hit this exception. Also some classes do maintain their own internal lists e.g ObjectOutputStream. So if you happen to use this, and you are not aware of the list, you may also hit an exception.

For most simple cases it's normally not neccesary to run a test with the verbose:gc option. But if you intend your program to run continuously for long periods of time, I do suggest taking some time to run it at least once or twice, and subject the application to high or higher than usual loads and monitor it's memory usage. To use it:

java -verbose:gc some_app

It will print out some info as to the memory usage status, how much it's using, the max..etc. There's quite a number of documents on how to read the output of verbose:gc..a quick google will lead you to them. Hope this helps..

Not everyone will agree that running with the verbose:gc option is a must..but I will say it depends on a case to case basis. Although Java has pretty good garbage collection, it's not perfect, and it can't compensate for developer mistakes. Better to be safe than sorry especially if your app is required to run for a long time..

Looks allright..

guess that depends on the nature of the app. But generally as long as a baseline post cleanup memory usage zone is determined, and over the course of time, the memory usage stays within the accepted zone, that's good enough. If after a certain period of time it strays from that zone, then it could indicate a possible leak or an object that cannot be removed for some reason.

When it comes to this, it is highly dependent on the nature of the app. The above only covers apps which return to a certain accepted idle state after a while (i.e doing nothing and all neccesary closures and cleanup has been performed)

This post has been edited by perror: Feb 8 2006, 11:29 PM