views:

67

answers:

2

I want to build a windows service that will use a remote encoding service (like encoding.com, zencoder, etc.) to upload video files for encoding, download them after the encoding process is complete, and process them.

In order to do that, I was thinking about having different queues, one for handling currently waiting files, one for files being uploaded, one for files waiting for encoding to complete and one more for downloading them. Each queue has a limitation, for example only 5 files can be uploaded for encoding at a certain time. The queues have to be visible and able to resurrect from a crash - currently we do that by writing the queue to an SQL table and managing the number of items in a separate table.

I also want the queues to run in the background, independent of each other, but able to transfer files from one queue to another as the process goes on.

My biggest question mark is about how to build the queues and managing them, and less about limiting the number of items in each queue.

I am not sure what is the right approach for this and would really appreciate any help.
Thanks!

A: 

There are various ways to approach this and it depends which one suits your case in terms of reliability and resilience/development cost/maintenance cost. You need to answer the question on the likes that what if server crashes, is it important to carry on what you were doing?

Queue can be implemented in MSMQ, SQL Server or simply in code and all queues in memory. For workflow you can use Windows Workflow Foundation, or implement it yourself which would be probably easier but change would be more difficult.

So if you give a few more hints, I should be able to help you better.

Aliostad
Thanks. Yes, it's crucial to pick up from the same spot I left if the server crashes. I'd be happy to give more info, just let me know what can be helpful.
Nir
If you need it to be fail-safe, I would store it in a SQL Server if I can afford to have since it is easier to work with and can be backed up. If not, I will use MSMQ which comes free with the Windows. For workflow, I would use just simple state machine in code.
Aliostad
Thanks @Aliostad.
Nir
A: 

You probably don't need to separate the work into separate queues, as long as they are logically separated in some way (tagged with different "job types" or such).

As I see it, the challenge is to not pick up and process more than a given limited number of jobs from the queue, based on the type of job. I had a somewhat similar issue a while ago which led to a question here on SO, and a subsequent blog post with my solution, both of which might give you some ideas.

In short my solution was that I keep a list of "tokens". When ever I want to perform a job that has some sort of limitation, I first pick up a token. If no tokens are available, I will need to wait for one to become available. Then you can use whatever queueing mechanism suitable to handle the queue as such.

Fredrik Mörk
Thanks, it's helpful but my question was trying to aim more at the management of separate queues. Your blog post was useful. thanks!
Nir
I agree with Fredrik. If you create 4 queues and assign a thread to each (or similar number of threads), it is possible that a slow queue (a queue which is responsible for a long-running process) would slow down your whole process since that queue is busy but the threads in the other queues are sitting and doing nothing. In any case, fine tuning these thread numbers could be difficult.
Aliostad
As it turns out, the blog post was extremely helpful. Thanks a lot!
Nir