I need to detect when my app is not responding, ie. when you get a MYAPP [Application Not Responding] in the Close Program box. I'm looking at having a small service application that fires off every few minutes and checks for app not responding. If this occurs then service app will log the fact, kill the main app and restart it and send an e-mail message to a predesignated address.
Something Like:
if MAIN_APP then // Check that MAIN_APP is running if MAIN_APP not_responding then // Check to see if it's responding begin // NOT responding Kill MAIN_APP Restart MAIN_APP Log Entry E-Mail fault details end else begin // NOT active for some reason Start MAIN_APP Log Entry E-Mail fault details end
Is there a component or simple API call that I can use to do this.
Note: I know I can setup a messaging link between the two apps and see if I get a response at reqular intervals, but I really didn't want the main app to have to do anything to prove it was not only alive, but functioning as well.
Kevin Black wrote in message <3b2e9...@news.iprimus.com.au>... >Hi,
>I need to detect when my app is not responding, ie. when you get a MYAPP >[Application Not Responding] in the Close Program box. I'm looking at >having a small service application that fires off every few minutes and >checks for app not responding. If this occurs then service app will log the >fact, kill the main app and restart it and send an e-mail message to a >predesignated address.
<snip>
>Note: I know I can setup a messaging link between the two apps and see if I >get a response at reqular intervals, but I really didn't want the main app >to have to do anything to prove it was not only alive, but functioning as >well.
And yet, I think this is what you have to do. Consider: the only thing you _can_ notice when a program is "not responding" is that it does not answer your messages. So you'll have to send (post, really) those and see if you get an answer. Then when you _don't_ get it, you can assume the program hangs.
Probing a program without looking at it is like estimating colour with your eyes closed. You can't see if you don't look.
That's not quite what I meant. I was thinking along the lines that the operating system can figure out that an app is 'not responding' so there must be a call (you would think) to access this data??? Again I'm happy to post a message and have the app respond with a post back, but if the info has already been generated or is available and my little service app can access this info there's no reason for the main app to become (conciously) involved.
Now if the info is dynamic, ie. the windows system call actually interrogates the app waiting for some sort of response, then I've got to assume that every winapp has an in-built responder of some sort, which I suspect is unlikely??
Regards, Kevin
Maarten Wiltink <mwiltin...@hccnet.nl> wrote in message
> Kevin Black wrote in message <3b2e9...@news.iprimus.com.au>... > >Hi,
> >I need to detect when my app is not responding, ie. when you get a MYAPP > >[Application Not Responding] in the Close Program box. I'm looking at > >having a small service application that fires off every few minutes and > >checks for app not responding. If this occurs then service app will log > the > >fact, kill the main app and restart it and send an e-mail message to a > >predesignated address.
> <snip>
> >Note: I know I can setup a messaging link between the two apps and see if > I > >get a response at reqular intervals, but I really didn't want the main app > >to have to do anything to prove it was not only alive, but functioning as > >well.
> And yet, I think this is what you have to do. Consider: the only > thing you _can_ notice when a program is "not responding" is that > it does not answer your messages. So you'll have to send (post, > really) those and see if you get an answer. Then when you _don't_ > get it, you can assume the program hangs.
> Probing a program without looking at it is like estimating colour > with your eyes closed. You can't see if you don't look.
Kevin Black wrote in message <3b2f4...@news.iprimus.com.au>... >Maarten,
>That's not quite what I meant. I was thinking along the lines that the >operating system can figure out that an app is 'not responding' so there >must be a call (you would think) to access this data??? Again I'm happy to >post a message and have the app respond with a post back, but if the info >has already been generated or is available and my little service app can >access this info there's no reason for the main app to become (conciously) >involved.
I doubt that such a call exists.
>Now if the info is dynamic, ie. the windows system call actually >interrogates the app waiting for some sort of response, then I've got to >assume that every winapp has an in-built responder of some sort, which I >suspect is unlikely??
It is called the windows procedure. Please tell me you do know about window procedures.
Essentially the OS could do it two ways: first is to probe the apps message queue on each time slice. If the messages go through, it thinks it's alive. The other way is to send it a message and wait for it to come back (just as you described earlier). I imagine they both accomplish the same thing, and it's probably easier to code the latter. If you look in the WinAPI helps under messaging you'll find a SendMessageTimeout function that you could use.
There is no "not_responding" application status per se.
Sterling
"Kevin Black" <kevinbl...@megabit.com.au> wrote in message
> That's not quite what I meant. I was thinking along the lines that the > operating system can figure out that an app is 'not responding' so there > must be a call (you would think) to access this data??? Again I'm happy to > post a message and have the app respond with a post back, but if the info > has already been generated or is available and my little service app can > access this info there's no reason for the main app to become (conciously) > involved.
> Now if the info is dynamic, ie. the windows system call actually > interrogates the app waiting for some sort of response, then I've got to > assume that every winapp has an in-built responder of some sort, which I > suspect is unlikely??
> Regards, > Kevin
> Maarten Wiltink <mwiltin...@hccnet.nl> wrote in message > news:9gn8on$7ii$1@news1.xs4all.nl... > > Kevin Black wrote in message <3b2e9...@news.iprimus.com.au>... > > >Hi,
> > >I need to detect when my app is not responding, ie. when you get a MYAPP > > >[Application Not Responding] in the Close Program box. I'm looking at > > >having a small service application that fires off every few minutes and > > >checks for app not responding. If this occurs then service app will log > > the > > >fact, kill the main app and restart it and send an e-mail message to a > > >predesignated address.
> > <snip>
> > >Note: I know I can setup a messaging link between the two apps and see if > > I > > >get a response at reqular intervals, but I really didn't want the main > app > > >to have to do anything to prove it was not only alive, but functioning as > > >well.
> > And yet, I think this is what you have to do. Consider: the only > > thing you _can_ notice when a program is "not responding" is that > > it does not answer your messages. So you'll have to send (post, > > really) those and see if you get an answer. Then when you _don't_ > > get it, you can assume the program hangs.
> > Probing a program without looking at it is like estimating colour > > with your eyes closed. You can't see if you don't look.
Thanks, and I've already used the API functionality to send and receive messages between apps. I was just trying to cut the main apps workload (it's busy acquiring and compressing images so it's pretty busy). Since the app is security focussed and generally unattended, I need to know if it goes splat so that remedial action can be taken hence the query.
Regards, Kevin
Sterling Bates <no...@nowhere.com> wrote in message
> Essentially the OS could do it two ways: first is to probe the apps message > queue on each time slice. If the messages go through, it thinks it's alive. > The other way is to send it a message and wait for it to come back (just as > you described earlier). I imagine they both accomplish the same thing, and > it's probably easier to code the latter. If you look in the WinAPI helps > under messaging you'll find a SendMessageTimeout function that you could > use.
> There is no "not_responding" application status per se.
> > That's not quite what I meant. I was thinking along the lines that the > > operating system can figure out that an app is 'not responding' so there > > must be a call (you would think) to access this data??? Again I'm happy > to > > post a message and have the app respond with a post back, but if the info > > has already been generated or is available and my little service app can > > access this info there's no reason for the main app to become (conciously) > > involved.
> > Now if the info is dynamic, ie. the windows system call actually > > interrogates the app waiting for some sort of response, then I've got to > > assume that every winapp has an in-built responder of some sort, which I > > suspect is unlikely??
> > Regards, > > Kevin
> > Maarten Wiltink <mwiltin...@hccnet.nl> wrote in message > > news:9gn8on$7ii$1@news1.xs4all.nl... > > > Kevin Black wrote in message <3b2e9...@news.iprimus.com.au>... > > > >Hi,
> > > >I need to detect when my app is not responding, ie. when you get a > MYAPP > > > >[Application Not Responding] in the Close Program box. I'm looking at > > > >having a small service application that fires off every few minutes and > > > >checks for app not responding. If this occurs then service app will > log > > > the > > > >fact, kill the main app and restart it and send an e-mail message to a > > > >predesignated address.
> > > <snip>
> > > >Note: I know I can setup a messaging link between the two apps and see > if > > > I > > > >get a response at reqular intervals, but I really didn't want the main > > app > > > >to have to do anything to prove it was not only alive, but functioning > as > > > >well.
> > > And yet, I think this is what you have to do. Consider: the only > > > thing you _can_ notice when a program is "not responding" is that > > > it does not answer your messages. So you'll have to send (post, > > > really) those and see if you get an answer. Then when you _don't_ > > > get it, you can assume the program hangs.
> > > Probing a program without looking at it is like estimating colour > > > with your eyes closed. You can't see if you don't look.
Kevin Black wrote in message <3b313...@news.iprimus.com.au>... >Sterling,
>Thanks, and I've already used the API functionality to send and receive >messages between apps. I was just trying to cut the main apps workload >(it's busy acquiring and compressing images so it's pretty busy). Since the >app is security focussed and generally unattended, I need to know if it goes >splat so that remedial action can be taken hence the query.
The main application would just have to respond to a single message every once in a while. Not much work really.
Realistically, if the acquisition/compression is enough work that you need to worry about it crashing, it sounds like it's at least several hours of computation. Probing it with a single message every ten seconds or so is completely negligible.
> Realistically, if the acquisition/compression is enough work > that you need to worry about it crashing, it sounds like it's > at least several hours of computation. Probing it with a single > message every ten seconds or so is completely negligible.
You miss the point, the system is acquiring, compressing and storing a single large image, it is acquiring, compressing and storing images from 9 cameras through our proprietary board (it's a security system). We do not (as yet) have hardware compression built into the board. It is continuously cycling from camera to camera at a frame rate of abou six 384x256 24bit colour images per second with one camera (permanent duty cycle, separate daughter board) capturing AVI (incl sound) at about 12 frames/sec. This ensures that the system is fully occupied all the time. Every interruption to this intense duty cycle is significant and we'd like to keep it to a minimum.
If the system crashes or if the application locks up we need to know, it means that 9 cameras have stopped acquiring images. In a service station (gas station for those of US descent) we have the AVI camera over the point of sale and the other 8 cameras monitoring pumps, rest room entrances etc etc. If there's an incident/robbery and our system is dead (and we didn't know about it, big trouble in little china).......
And, sure we could have image acquisition based on alarm activation (we have software motion detect and 8 dry contact alarm inputs to the board), but our customers want continuous monitoring and recording.
> > Realistically, if the acquisition/compression is enough work > > that you need to worry about it crashing, it sounds like it's > > at least several hours of computation. Probing it with a single > > message every ten seconds or so is completely negligible.
> You miss the point, the system is acquiring, compressing and storing a > single large image, it is acquiring, compressing and storing images from 9 > cameras through our proprietary board (it's a security system). We do not > (as yet) have hardware compression built into the board. It is continuously > cycling from camera to camera at a frame rate of abou six 384x256 24bit > colour images per second with one camera (permanent duty cycle, separate > daughter board) capturing AVI (incl sound) at about 12 frames/sec. This > ensures that the system is fully occupied all the time. Every interruption > to this intense duty cycle is significant and we'd like to keep it to a > minimum.
> If the system crashes or if the application locks up we need to know, it > means that 9 cameras have stopped acquiring images. In a service station > (gas station for those of US descent) we have the AVI camera over the point > of sale and the other 8 cameras monitoring pumps, rest room entrances etc > etc. If there's an incident/robbery and our system is dead (and we didn't > know about it, big trouble in little china).......
> And, sure we could have image acquisition based on alarm activation (we have > software motion detect and 8 dry contact alarm inputs to the board), but our > customers want continuous monitoring and recording.
"Kevin Black" <kevinbl...@megabit.com.au> wrote in message
ISTM that it would make more sense to have the capturing software post "I'm up" messages at appropriate times in their processing. The monitor then just has to run timers for each of the captures that are active, resetting the interval whenever a message is received.
Kevin Black wrote in message <3b372...@news.iprimus.com.au>... >Maarten,
>> Realistically, if the acquisition/compression is enough work >> that you need to worry about it crashing, it sounds like it's >> at least several hours of computation. Probing it with a single >> message every ten seconds or so is completely negligible.
>You miss the point, the system is acquiring, compressing and storing a >single large image, it is acquiring, compressing and storing images from 9 >cameras through our proprietary board (it's a security system). We do not >(as yet) have hardware compression built into the board. It is continuously >cycling from camera to camera at a frame rate of abou six 384x256 24bit >colour images per second with one camera (permanent duty cycle, separate >daughter board) capturing AVI (incl sound) at about 12 frames/sec. This >ensures that the system is fully occupied all the time. Every interruption >to this intense duty cycle is significant and we'd like to keep it to a >minimum.
OK, I had assumed it was an off-line system. But it's not, and that changes things. I would suggest integrating crash detection into the board. Also, if you can't currently spare _any_ cycles, you really should put a slightly faster CPU in there. Why is this thing running Windows anyway?
>If the system crashes or if the application locks up we need to know, it >means that 9 cameras have stopped acquiring images. In a service station >(gas station for those of US descent) we have the AVI camera over the point >of sale and the other 8 cameras monitoring pumps, rest room entrances etc >etc. If there's an incident/robbery and our system is dead (and we didn't >know about it, big trouble in little china).......
>And, sure we could have image acquisition based on alarm activation (we have >software motion detect and 8 dry contact alarm inputs to the board), but our >customers want continuous monitoring and recording.
All this just means one thin: Think Embedded. And since I don't, I'll shut up now. (-:
History, paradigm change and development under Linux started. You are not the first to ask this question:)
> All this just means one thin: Think Embedded. > And since I don't, I'll shut up now. (-:
We have looked at the RTXX type OS and it would probably be a good thing, but the initial costs were prohibitive (for our shoe-string budget anyway) so Linux looks the go. We know of one system built with our image capture boards used in 'in-vehicle' surveilance where a cut down Linux kernel was used.
|
