BrianMc1958
asked on
How to know if another JVM is running?
Dear Experts,
I need to figure how to notify myself when my Java application stops running. I'm imagining another Java application, running in a separate JVM, that acts as a daemon and does nothing but check if the other application is running. It will email me if not. It will sleep most of the time.
I must use another JVM, because my customer ends my application by killing the entire JVM.
Is there any way for a class in one JVM to know if another JVM is even running? (I'm running on Windows.)
If so, is there any way to know which classes the other JVM has loaded?
BTW, I know I can solve this by having the watcher check for any changes in my application's log file, but that's not ideal. It would be better to check directly if I can.
Thanks!
BrianMc1958
I need to figure how to notify myself when my Java application stops running. I'm imagining another Java application, running in a separate JVM, that acts as a daemon and does nothing but check if the other application is running. It will email me if not. It will sleep most of the time.
I must use another JVM, because my customer ends my application by killing the entire JVM.
Is there any way for a class in one JVM to know if another JVM is even running? (I'm running on Windows.)
If so, is there any way to know which classes the other JVM has loaded?
BTW, I know I can solve this by having the watcher check for any changes in my application's log file, but that's not ideal. It would be better to check directly if I can.
Thanks!
BrianMc1958
CEHJ
It would be easy if you were to arrange for the first app to open a Socket. The second can try likewise on the same port
Could you not override finalize() in the Object class to do this?
You could also get the first app to create a lock file
>> I need to figure how to notify myself when my Java application stops running.
Use a shut-down hook to send yourself an alert (through e-mail, etc) in your Java app. No other apps required.
Use a shut-down hook to send yourself an alert (through e-mail, etc) in your Java app. No other apps required.
>> I'm running on Windows
You can also write native code in Windows to get the list of currently running processes - you could deploy it as a Windows service which runs forever and checks if the Java app has stopped periodically. I'd still prefer the shut-down hook (it will be invoked before the JVM exits).
You can also write native code in Windows to get the list of currently running processes - you could deploy it as a Windows service which runs forever and checks if the Java app has stopped periodically. I'd still prefer the shut-down hook (it will be invoked before the JVM exits).
http://javaalmanac.com/egs/java.lang/ExitHook.html
>> It would be easy if you were to arrange for the first app to open a Socket. The second can try likewise on the same port
CEHJ, I hope you didn't mean that as a production solution ;-) ? Why open a port.... the same port might be required by another app. Of course the file-lock is better.
>> It would be easy if you were to arrange for the first app to open a Socket. The second can try likewise on the same port
CEHJ, I hope you didn't mean that as a production solution ;-) ? Why open a port.... the same port might be required by another app. Of course the file-lock is better.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
A shutdown hook may not work when the application is killed.
The sample code above can also REUSE the lock, passing it from application to application.
;JOOP!
The sample code above can also REUSE the lock, passing it from application to application.
;JOOP!
>> my customer ends my application by killing the entire JVM.
It will work for these cases (normal termination) if the requirement is to trap only those.
Somehow I don't like the idea of having another process running all the time simply for checking if this one is alive or not....
It will work for these cases (normal termination) if the requirement is to trap only those.
Somehow I don't like the idea of having another process running all the time simply for checking if this one is alive or not....
Yes - my second suggestion was better than my first ;-)
ASKER
Yikes!
To mayankeagle: WHAT is a shut-down hook? That sounds ideal. Whatever it is, will it still work even when the JVM itself is being manually shut down? What about when the server itself is shutting down unexpectedly?
To colr__ : I've never actually used finalize().
To everybody: I should have mentioned my application is fairly complex, and I have no idea which of many classes might be running when it ends (unexpectedly). It does have some sort of "main loop", which controls all processing. If I were to use a "shut-down hook" or finalize(), is that where it would go? Assuming this is my app:
public class FS_MainDriver
{
public static void main(String args[])
{
boolean done = false;
while (!done)
{
// go do complicated things
}
}
}
To mayankeagle: WHAT is a shut-down hook? That sounds ideal. Whatever it is, will it still work even when the JVM itself is being manually shut down? What about when the server itself is shutting down unexpectedly?
To colr__ : I've never actually used finalize().
To everybody: I should have mentioned my application is fairly complex, and I have no idea which of many classes might be running when it ends (unexpectedly). It does have some sort of "main loop", which controls all processing. If I were to use a "shut-down hook" or finalize(), is that where it would go? Assuming this is my app:
public class FS_MainDriver
{
public static void main(String args[])
{
boolean done = false;
while (!done)
{
// go do complicated things
}
}
}
finalize() will be called when an object is destroyed. Ive never actually used it either, but I suspect it might be useable by yourself to detect the shutdown of the app, regardles of where it happans. Correct me if Im wrong people, I would like to know!!!
As standard it doesnt do anythign, although it still gets called on destruction of every object - you'd just override it to perform the functionality you want on the detsroying of the object.
As standard it doesnt do anythign, although it still gets called on destruction of every object - you'd just override it to perform the functionality you want on the detsroying of the object.
You would use the lock file *in conjunction with* a shutdown hook, or another app won't be able to tell if it's running
ASKER
Are "shut-down hook" and "finalize()" the same thing?
colr_ , there is no finalize() at any ending of an application! That's the big complaint of proframmers against SUN.
;JOOP!
;JOOP!
No. finalize pertains to class unloading, shutdown to vm shutdown
http://mindprod.com/jgloss/finalize.html
http://mindprod.com/jgloss/finalize.html
A shutdown hook is a thread that should be executed by the call System.exit();
;JOOP!
;JOOP!
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
To everybody: Thanks for all the responses! I won't have time to try them out until later in the day. Will respond again then... I'll still be reading, though, if anyone has anything else to say. (Interesting topic, eh? When a Java class in being unloaded, does it see some bright light or something? Virtual angels?)
--BrianMc1958
--BrianMc1958
JAVA class unloaded? forget that.
Btw.: I use my solution when one of my apps re-installs a new version of itself.
The new version must wait until the old version, that started the new version has exited.
Works as a charm.
;JOOP!
Btw.: I use my solution when one of my apps re-installs a new version of itself.
The new version must wait until the old version, that started the new version has exited.
Works as a charm.
;JOOP!
>> When a Java class in being unloaded, does it see some bright light or something?
That's a different story altogether....
That's a different story altogether....
> You would use the lock file *in conjunction with* a shutdown hook, or another app won't be able to tell if it's running
another application would not need to tell if it was running.
shutdown hook is all you need.
another application would not need to tell if it was running.
shutdown hook is all you need.
Thanks Mick
>>another application would not need to tell if it was running
Why not?
Why not?
More info on a shutdown hook here: http://www.onjava.com/pub/a/onjava/2003/03/26/shutdownhook.html
alternativelly: http://wrapper.tanukisoftware.org/doc/english/index.html
>> Why not?
CEHJ, I don't like the idea of having another application running in the background, eating CPU and memory for nothing but just periodically checking if another application was running - do you think its a good idea?
CEHJ, I don't like the idea of having another application running in the background, eating CPU and memory for nothing but just periodically checking if another application was running - do you think its a good idea?
And I don't like "professional" situations where the only valid
ending for an application seems to be a killing by a customer.
;JOOP!
ending for an application seems to be a killing by a customer.
;JOOP!
>>do you think its a good idea?
It seems to me to be essential. How can an application that's *not* running check if it's running?
It seems to me to be essential. How can an application that's *not* running check if it's running?
> do you think its a good idea?
absolutely not, especially as its unnecessary in this case. And do you run *another* application to make sure your monitor app is running :-D
Shutdown hook handles this situation just fine all by itself.
absolutely not, especially as its unnecessary in this case. And do you run *another* application to make sure your monitor app is running :-D
Shutdown hook handles this situation just fine all by itself.
>> And I don't like "professional" situations where the only valid ending for an application seems to be a killing by a customer.
Obviously in professional/ production situations, anything can happen and the situations being referred to were not the only professional ones in case you mistook it. We never said that the application can be ended *only* by the customer. We said we wanted to know whether those were the only cases (normal terminations) that were relevant for discussion, or do we have to do this for abnormal termination too, because the way the question mentions it, it looks like normal termination is the only one we are interested in: >> my customer ends my application by killing the entire JVM.
>> How can an application that's *not* running check if it's running?
That's what - the requirement is for the running application to somehow inform before it shuts down - whether you use another application to trap it, or make the existing application use a shut-down hook is only a design consideration which comes later depending on whether you want to trap improper shut-down too, or only normal shut-down.
Obviously in professional/ production situations, anything can happen and the situations being referred to were not the only professional ones in case you mistook it. We never said that the application can be ended *only* by the customer. We said we wanted to know whether those were the only cases (normal terminations) that were relevant for discussion, or do we have to do this for abnormal termination too, because the way the question mentions it, it looks like normal termination is the only one we are interested in: >> my customer ends my application by killing the entire JVM.
>> How can an application that's *not* running check if it's running?
That's what - the requirement is for the running application to somehow inform before it shuts down - whether you use another application to trap it, or make the existing application use a shut-down hook is only a design consideration which comes later depending on whether you want to trap improper shut-down too, or only normal shut-down.
>>That's what - the requirement is for the running application to somehow inform before it shuts down
That's not the *whole* requirement:
>>my customer ends my application by killing the entire JVM.
A shutdown hook won't help you there
That's not the *whole* requirement:
>>my customer ends my application by killing the entire JVM.
A shutdown hook won't help you there
>> A shutdown hook won't help you there
Why? If the VM shut-down is not improper, it should be executed.
>> That's not the *whole* requirement:
Brian - pls clarify. Also how exactly does the customer shut down the VM?
Why? If the VM shut-down is not improper, it should be executed.
>> That's not the *whole* requirement:
Brian - pls clarify. Also how exactly does the customer shut down the VM?
>>Why? If the VM shut-down is not improper, it should be executed.
This to me sounds like the process will be killed
>>by killing the entire JVM
This to me sounds like the process will be killed
>>by killing the entire JVM
Why not use JMX?
http://java.sun.com/products/JavaManagement/
Suggestions above *will* work but you are using your own techniques. JMX can provide a way to manage what you want to do. You'd still need that always running "Agent" to be able to start/stop your server but JMX can provide a mechanism to monitor whether the server is running without writing your own socket handling.
Also, there are many UIs that are available to provide a management view of your application.
This is the correct way to manage an application but is maybe not as lightweight as the suggestions above.
Andrew
http://java.sun.com/products/JavaManagement/
Suggestions above *will* work but you are using your own techniques. JMX can provide a way to manage what you want to do. You'd still need that always running "Agent" to be able to start/stop your server but JMX can provide a mechanism to monitor whether the server is running without writing your own socket handling.
Also, there are many UIs that are available to provide a management view of your application.
This is the correct way to manage an application but is maybe not as lightweight as the suggestions above.
Andrew
> A shutdown hook won't help you there
rotfl, thats what shutdown hooks are for :-D
> Also, there are many UIs that are available to provide a management view of your application.
> This is the correct way to manage an application but is maybe not as lightweight as the suggestions above.
Absolutely right, if there is a need to monitor an application you don't go writing another application to do it. Thats just silly.
rotfl, thats what shutdown hooks are for :-D
> Also, there are many UIs that are available to provide a management view of your application.
> This is the correct way to manage an application but is maybe not as lightweight as the suggestions above.
Absolutely right, if there is a need to monitor an application you don't go writing another application to do it. Thats just silly.
>>rotfl, thats what shutdown hooks are for :-D
So you think a shutdown hook will run if the process is killed do you? ;-)
So you think a shutdown hook will run if the process is killed do you? ;-)
ASKER
I guess I did pick an interesting topic.
>>Brian - pls clarify. Also how exactly does the customer shut down the VM?
In general, I need a way to know if my app has stopped running REGARDLESS of WHY. It should run 24/7, although it sleeps most of that time. Although there is a way to shut it down cleanly, my customer kills the JVM because it's quicker.
I have tested the shutdownhook, and it only works (here, anyway) when the JVM shuts down normally. When I kill java.exe thru Windows Task Manager, it does not work. (Neither does an overridden finalize()).
I'm about to try sciuriware's technique. (It looks cool.) I didn't want a whole other separate watcher either, but I can't see another way right now. I will be able to schedule it to run hourly, anyway, which is good enough for me, and won't chew up a lot of resources.
As always, I'm very grateful you all would take so much time to answer my questions.
>>Brian - pls clarify. Also how exactly does the customer shut down the VM?
In general, I need a way to know if my app has stopped running REGARDLESS of WHY. It should run 24/7, although it sleeps most of that time. Although there is a way to shut it down cleanly, my customer kills the JVM because it's quicker.
I have tested the shutdownhook, and it only works (here, anyway) when the JVM shuts down normally. When I kill java.exe thru Windows Task Manager, it does not work. (Neither does an overridden finalize()).
I'm about to try sciuriware's technique. (It looks cool.) I didn't want a whole other separate watcher either, but I can't see another way right now. I will be able to schedule it to run hourly, anyway, which is good enough for me, and won't chew up a lot of resources.
As always, I'm very grateful you all would take so much time to answer my questions.
>> When I kill java.exe thru Windows Task Manager, it does not work
Yes, in that scenario it won't.
>> I need a way to know if my app has stopped running REGARDLESS of WHY
I'm afraid in that case, you need to perhaps try the file-lock or maybe astorer's technique.
Yes, in that scenario it won't.
>> I need a way to know if my app has stopped running REGARDLESS of WHY
I'm afraid in that case, you need to perhaps try the file-lock or maybe astorer's technique.
Here's the JMX way...
You instantiate an MBeanServer and provide it with an MBean in your app that is used to report on whether your application is running.
A JMX client/Admin console is responsible for periodically checking that MBeanServer and checking to see whether your app is still alive. If your app is not alive, the JMX client should raise a notification (just use log4j - you can then map that to a log file, send email, windows event log etc.)
That's how you'd usually do such a thing in an enterprise app.
You instantiate an MBeanServer and provide it with an MBean in your app that is used to report on whether your application is running.
A JMX client/Admin console is responsible for periodically checking that MBeanServer and checking to see whether your app is still alive. If your app is not alive, the JMX client should raise a notification (just use log4j - you can then map that to a log file, send email, windows event log etc.)
That's how you'd usually do such a thing in an enterprise app.
ASKER
To astorer: Thank you for your suggestion, but we've just got sciuriware's solution running, and we don't have time to look into yours. Maybe next year...
To sciuriware: Can't thank you enough. It works beautifully. Our customer (already) is very happy. My boss is very happy. I am very, very happy. I hope you are happy at least well into next week!
To everybody: Once again, thank you all so much for your help. This has been not only very important to my little company, but very educational and fun, too.
To sciuriware: Can't thank you enough. It works beautifully. Our customer (already) is very happy. My boss is very happy. I am very, very happy. I hope you are happy at least well into next week!
To everybody: Once again, thank you all so much for your help. This has been not only very important to my little company, but very educational and fun, too.
ASKER
p.s.: To anyone reading this, sciuriware provided the core solution in the answer I'll "accept", and then the simple implementation in a later answer I'll also award points for. Hope they add up OK...
>>Can't thank you enough. It works beautifully.
Good. Yes - use a lock file as i mentioned ;-)
Out of interest, is it still working well when the process is killed?
Good. Yes - use a lock file as i mentioned ;-)
Out of interest, is it still working well when the process is killed?
If so many people are happy, I'm honoured!
;JOOP!
;JOOP!
ASKER
>>Out of interest, is it still working well when the process is killed?
Yes. I kill the whole JVM manually, and it works just fine. The "watcher", of course, is running in a separate JVM, periodically. So far it's been perfect.
Yes. I kill the whole JVM manually, and it works just fine. The "watcher", of course, is running in a separate JVM, periodically. So far it's been perfect.
You should've perhaps given some points to CEHJ too - he had suggested the same idea.
>>The "watcher", of course, is running in a separate JVM, periodically.
Ah OK - as i mentioned an app can't watch itself ;-)
Ah OK - as i mentioned an app can't watch itself ;-)
mayankeagle, sometimes the one who effectively gave the right answer is awarded,
then sometimes the one who made it ... digestible.
I'm sure you would have understood the first answer fully.
;JOOP!
then sometimes the one who made it ... digestible.
I'm sure you would have understood the first answer fully.
;JOOP!
Thanks for thinking of me mayank ;-)
Hey CEHJ, I think of you all the time! How could I ignore someone with over 5 000 000 points in JAVA alone!
;JOOP!
;JOOP!
;-)
This should not be misunderstood by others .....
Sorry it's 36 Celcius here ....
>> sometimes the one who effectively gave the right answer is awarded
Correct, nobody's denying your efforts ;-) just thought CEHJ deserved some of the points too for hinting in the right direction initially.
Correct, nobody's denying your efforts ;-) just thought CEHJ deserved some of the points too for hinting in the right direction initially.
You are so right. Yesterday I was ignored somewhere. The "asker" rules.
;JOOP!
;JOOP!
Yeah, those happen very often :)