1

Suppose a web API is called with some regular frequency throughout the day, 20x an hour. The actions that begin after the API is called are long running and can go for minutes each.

I need to process the tasks in order grouped in a certain way. E.G. The company these requests come from need to be queued in order, but ones from other companies may be run in parallel in their own group at the same time.

Instead of using a queue and a loop thread, can I have a dictionary that's of GroupId, Task and just append a new task with ContinueWith every time a request comes in for that group?

I've tested it out with about a request per 10 milliseconds for 10k requests. It ran fine, but I wanted some opinions with any experience or ideas on how this could work in a production environment.

tylerjgarland
  • 643
  • 6
  • 19

1 Answers1

3

The fundamental approach is sound. You can abstract away the mechanism that you're using from the business logic of it by creating a TaskQueue class that manages the queue of items for you, allowing you to deal with that concept as an abstraction (you haven't shown your code, but you do need to be careful when appending these continuations to ensure that you don't have race conditions when two items are trying to append themselves at the same time). It's not particularly hard to do, but it's quite useful as it means you don't need to think about difficult low level threading issues in your business logic.

Here is an example of such a class that you can use for this.

Community
  • 1
  • 1
Servy
  • 202,030
  • 26
  • 332
  • 449
  • I was using a ConcurrentDictionary to maintain the group id + Task but thanks for the heads up. It's at a POC phase right now. – tylerjgarland Nov 18 '16 at 23:46
  • just checked out your code and that's exactly what I'm envisioning. You haven't seen this degrade over time? I was curious if a task with 1 million continuations after running for a few months would have some memory leaks. – tylerjgarland Nov 18 '16 at 23:55
  • @tylerjgarland If implemented properly, no. – Servy Nov 21 '16 at 14:21