because waiting_queue workers can live for a loooooong time, the code they load can be older than the on-disk code, which is almost certainly ungood.
we need to provide a mechanism to signal to a worker that it should kill itself, so that whatever process that manages the worker will start a new one.
this mechanism needs to be clean - it needs to happen between jobs, not during a job.
quick discussion with sdboyer, we thought perhaps a custom signal handler is one possibility.
| Comment | File | Size | Author |
|---|---|---|---|
| #8 | reboot.patch | 2.59 KB | Anonymous (not verified) |
| #5 | reboot.on_.sigterm.patch | 2.78 KB | Anonymous (not verified) |
| #3 | reboot.on_.sigterm.patch | 2.4 KB | Anonymous (not verified) |
Comments
Comment #1
sdboyer commentedgiven that the goal here is pretty much by definition to force the reboot externally, I can't think of another way to do it apart from signal handlers that would be simple, effective, and scalable (and really, this is what signals are *for*). the only other alternative I can even think of is some sort of db-recorded timestamp which the workers individually check whenever
claimItem()finishes, and compare against their own start time. i don't really like that, though, as a) it means an extra query for every job and b) potentially a *lot* of concurrent queries on that table.But most importantly, because there are other reasons we might want to force a restart. Signals are the generic solution to that problem, so that's the way we should go.
and...I GUESS we separate it so that we can be cognizant of Windows compatibility. Meh. :P
Comment #3
Anonymous (not verified) commentedpatch against 7.x, will backport to 6.x when we're happy.
Comment #4
msonnabaum commentedLooks good to me. Should we also handle SIGINT though?
Comment #5
Anonymous (not verified) commentedwhen writing the patch i was thinking we should make the signal(s) that will trigger a reboot configurable. the emphasis is on not forcing the use of a particular signal on people using workers, rather than on being a general purpose signal handling setup.
attached patch makes the signals the will cause a reboot configurable, and defaults to SIGTERM.
Comment #6
sdboyer commentedI think I'd rather see the object install the signal handlers on itself (say in a
installHandlers()method). Haven't found a way to remove them, but if there is one, then it should be triggered in the object's__destruct().Also should put in at least nominal winblows support. Or at least an
if function_exists(pcntl_signal()) { ... } else { watchdog() }type of thing.Comment #7
Anonymous (not verified) commentedok, i agree with the object installing the handlers itself.
not sure i care about windows support, but it's definitely worth checking for pcntl_signal. working up patch now...
Comment #8
Anonymous (not verified) commentedhere it is.
Comment #9
sdboyer commented+1.
...though i don't actually have a good spot to test this. have you? :)
Comment #10
Anonymous (not verified) commentedhttp://drupalcode.org/project/waiting_queue.git/commit/aee767d
finally got around to this...