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
    Thank you for the input. You state that they don't scale well for 1000s of jobs. Unfortunately, this is the case. The enqueue thread received hundreds of thousands of jobs in a day. So, this probably isn't going to work for my needs. I appreciate the feedback and will probably play with IPC::DirQueue for other things. Thank you.

      Depending on the nature of the jobs, you can follow the usual approach and use the first two letters or some other (evenly distributed!) criteria to distribute the jobs among subdirectories. This makes scanning for fresh jobs harder though. Alternatively, move jobs that are "in processing" into a separate directory which is not scanned. That will reduce the load that idle jobs produce while scanning for work to do.

      If you have to have a high throughput and can't batch your 100k requests into jobs of (say) 100 items or so, I'd look at premade solutions or maybe just at dedicating a database machine which serves as the central job directory.