I am using a thread in Java to re-run a section of code. The problem is I am not sure what is the impact of such action if I place it into a server. In short, this java program will never exit ... I placed thread.sleep(50000000), so the program will stay idle for 500000000 milliseconds before the next thread will fire up ...

My concern is whether it will eat up all the RAM if it runs without exiting for several weeks in the server ... BTW, the server is UNIX base where a shell script is being run to initiate this java program...

to all the gurus ... please let me a hand

thank you

May i know wat are u trying to achieve here?Btw,u may like to check out Quartz,a Java scheduler...I don't really like to write my own thread unless its really necessary...usually i will use Quartz other other open source tools to ease my work,plus i m a web based programmer,so multithread isnt much of my concern as servlet or j2ee is already multithreaded...
if u plan to use quartz,i can give u some advice on ur situation,put ur section of code that u wish to re-run in a class and add this class into ur quartz schedule,then write another apps to start only the quartz scheduler(please refer to quartz website for this) and thats it...try to run the apps for couple of days without shuhtting down the apps,if the memory running low means ur java coding got memory leaking problem,review ur code and optimize it,if the problem still occurs,write another scheduler job to run GC...happy coding...

Unless you keep on spawning threads which the thread itself running endlessly. You should teoritically won't run out of RAM or CPU processing.

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?

THanks for ya reply, the main program will spawn only one thread which will do all the stuff. It will call the main function over and over again.

Thx perror, I have tried to use crontab but the cron itself dies halfway, it stops running every now and then which is really painful, we don't know whats the cause ....

the thread is in an infinite loop i placed while(true){ thread codes in here } so this program will never ends. I did not place any System.exit at all except when the program encounters an exception. In that infinit loop, is the thread.sleep(5000000)
I am aiming for 5 minutes, have not do the calculation so , thus although it is infinite, the thread will sleep for 5 minutes before calling the function again ...

please let me know whether it is a good idea to place this never ending story into the server

thanks

This post has been edited by Hou_JaI: Feb 4 2006, 07:53 PM

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..

thx perror,

anyway have place the thing into a test environment...and I can't seem to measure the thing....

verbose:gc wow, never heard of it ... can u please give me a head start with it?

by the way, if I assigned all the string variable to null and all int to 0, will this help to avoid memory leakage?

any other reasons which will cause memory leak?

This post has been edited by Hou_JaI: Feb 6 2006, 05:45 PM

For Java, your main concern is not about memory leak (with the exception of objects added in some custom containers)... you need to worry more on other kind of resources like connections and mutexes.

correct me if i am wrong, when i ran this particular program locally and i open up task manager and notice that the RAM USAGE keeps increasing (4-8k) after several minutes ... hmm is this memory leaking ?

its like going up without coming down ...

for connections, I think i have closed them and re-initiate them when a new run starts...

but for mutexes ...

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..

thx perror have used the verbose:gc while running the app. below is the smap shot of the GC

[GC 1775K->1321K(2872K), 0.0007023 secs]
[GC 1833K->1322K(2872K), 0.0006950 secs]
closed Log4jConfigurator for stream 1
[GC 1834K->1355K(2872K), 0.0006355 secs]
[GC 1867K->1356K(2872K), 0.0005908 secs]
closed Log4jConfigurator for stream 2
[Full GC 1829K->1352K(2872K), 0.0314841 secs]
[GC 1864K->1410K(2872K), 0.0007640 secs]
[GC 1922K->1411K(2872K), 0.0006949 secs]
closed Log4jConfigurator for stream 1
[GC 1923K->1445K(2872K), 0.0005891 secs]
[GC 1957K->1445K(2872K), 0.0005804 secs]
closed Log4jConfigurator for stream 2
[Full GC 1918K->1377K(2872K), 0.0315209 secs]
[GC 1889K->1435K(2872K), 0.0011096 secs]
[GC 1947K->1435K(2872K), 0.0006838 secs]
closed Log4jConfigurator for stream 1
[GC 1947K->1469K(2872K), 0.0006275 secs]
[GC 1981K->1469K(2872K), 0.0006032 secs]
closed Log4jConfigurator for stream 2
[Full GC 1942K->1263K(2872K), 0.0318728 secs]
[GC 1775K->1321K(2872K), 0.0009092 secs]
[GC 1833K->1322K(2872K), 0.0006947 secs]
closed Log4jConfigurator for stream 1
[GC 1834K->1356K(2872K), 0.0005901 secs]
[GC 1868K->1356K(2872K), 0.0005914 secs]
closed Log4jConfigurator for stream 2
[Full GC 1830K->1263K(2872K), 0.0358891 secs]

It seems like the GC is doing a good job, don't u think so ?

Looks allright..

GC based program, it is hard to notice a pattern that denotes a memory leak. GC sweeping are indeterministic. It might go up for sometime and suddenly the program jerk a little, and memory usage is back to normal.

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