The simplest thing to do is eliminate the queue. Just say that when you try to create a PDF, it sees if one is being created, and if it is it just retries later. Eventually you get through. Simple, dumb, and in my experience almost always sufficient.
If you want to get fancier, have a simple job table. When you ask for a PDF, it adds a record saying that person X wants PDF Y. A process is sitting there creating PDFs, which are placed in a temporary area for a bit, then cleaned up. At any time through a simple query you can see where someone is in line. If the person doesn't pick it up in time, they lose and have to resubmit the request. (With some cleverness you can do quite a bit with a surprisingly simple job system...)
The next simplest is to modify the job table to allow people to cancel jobs. Again, the default is that work gets done, but people can remove their job from the queue.
After that you can modify it to say that any job that is not updated regularly to say that you're still waiting is considered cancelled. And there you have it.
BTW while you're optimizing this, note that while you might not be able to create 500 PDFs at once, you'll probably be able to create 5 at once faster than 5 sequentially. So introduce some naive parallelism by having 5 workers trying to take jobs. That will improve throughput, and will also keep one person with a large job from blocking everyone else until their job is done.
In reply to Re: How would you implement a FIFO non-blocking queue?
by tilly
in thread How would you implement a FIFO non-blocking queue?
by BMaximus
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |