in reply to Persistent File Queue recommendation requested
Have a look at IPC::DirQueue, or use files in the file system as jobs and directories as their respective state yourself. On sane (that is, non-NFS) filesystems, rename is atomic and hence you can acquire a job by renaming it to "state1/$filename.$$", and once it is completed, rename it to "state2/$filename" for others to see. Restarting a job is as easy as renaming the corresponding file, and finding abandoned jobs means checking whether the PID corresponding to the file still exists.
If you want to expand this scheme across machines (with a shared directory holding the data, see my caution against NFS above), note that the PID is not unique anymore, so you will need to add the machine name as well as the PID to the file.
I haven't used IPC::DirQueue myself, but I have worked with similar schemes, and they have the benefit that you have lots of user tools already available. They don't scale well over 1000 jobs due to file system limitations and the rescanning, but if you have higher requirements, a dedicated (single point of failure) job queue server like SMTP might be a better option.
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re^2: Persistent File Queue recommendation requested
by r1n0 (Beadle) on Jan 27, 2010 at 14:30 UTC | |
by Corion (Patriarch) on Jan 27, 2010 at 14:36 UTC |