Re^2: Object Destructors and Signals

Thats reasonable. However, in my case the frontend and the perl backend are on different hosts. In fact, there are >12 perl workers on different hosts and 1 frontend on a remote webserver. Hence the communication via the DB.

I do cleanup "stuck" entries after a while. After 24 hours I go and set their status to "Failed" or "Aborted" I'm just trying to catch the failure sooner rather than later.

Comment on Re^2: Object Destructors and Signals

Replies are listed 'Best First'.
Re^3: Object Destructors and Signals by ikegami (Patriarch) on Nov 05, 2010 at 18:46 UTC
I'm just trying to catch the failure sooner rather than later. The more often the worker updates the "I'm alive" timestamp, the sooner you can catch failures. It sounds like it doesn't update the timestamp at all right now.	[reply]
Re^4: Object Destructors and Signals by bot403 (Beadle) on Nov 05, 2010 at 19:41 UTC
Oh I see. I have a generic "This row was last updated @" timestamp. I dont have an "I'm Alive" timestamp. Currently, working with the object involves spawning an external process that might not return for 1 minute or 100. I'm not sure when I'd get the chance to update the "I'm alive" timestamp while that operation is happening unless I spawned threads. However, its a neat idea and is hitting on a more genreal approach of using some sort of watchdog process either external or internal.	[reply]