2
Hello.
I'm facing a bit of an annoying indecision regarding the design of a particular component of my solution.
Perhaps there's someone who can offer some experience/creative insight into it?
Here's my scenario: I'm buiding a windows service that calls an xml web service and deals with the responses appropriately. this 'service agent' picks messages from a transactional message queue one at a time, attempts the web call, if it fails, raises the priority of the message and puts it back in the queue. It does this a certain number of pre-configured times before failing completely and notifying the user. I've realized though, that the time it takes per web call could vary, depending on the type of request. So my answer to this was to have multiple instances of the service agent running on separate threads, that each processes the next message in the queue when they are available, so if one web call gets held up, another thread can continue processing requests. I've tested and this works fine in principal, but the design decision i need to make is this:
1. Do i use the .net ThreadPool class with an array of waithandles to create the threads?
2. Do i use an array of instantiated Thread objects? BackgroundWorkers?
3. Do i use one BackgroundWorker to read the next message off the queue which fires off the processing thereof on a separate thread? (if so, how do i limit the number of concurrent threads?)
4. Is there a better way to do this, bearing in mind my intention is to have a small number of threads each running 1 method that (theoretically) never ends?
I have managed to use threading pretty efficiently in the past, but I want to implement the optimum solution here as resources and uptime are both critical.
Any input appreciated.
Dave
