Question

Network protocol parser code, parse below layers in single thread. After parsing some procotol get id that unique of dialogs.
For network protocol parser project; there is a message parser, parse messages that has multiple layers (eg. ethernet, ip,tcp etc). One of parsing field is dialog id that middle of layers; it means that need to some parsing operations before getting it. After getting dialog id parsing operation should(because of performance) multithread. Constraint is messages that have same dialog id should process in same order. I have some ideas but not sure is elegant.

1. Create 10 queue that last digit of dialog id, each queue parsing separate threads.
2. Multiple executors for modula operation with respect to dialog id similar first option.

How can process messages as multithread?

More explanations;
There are more than one message same dialog id and it should process same order.These is no correlation between dialog ids, i mean dialog id = 100 can process before dialog id = 99.

Example Incoming order of messages

1. Dialog id = 100
2. Dialog id = 99
3. Dialog id = 98
4. Dialog id = 100
5. Dialog id = 100
6. Dialog id = 98
7. Dialog id = 99

Message 4 should process before message 5 after message 1. There is no any order between Message 4 – Message 2 or Message 4 – Message 3 etc..

Answer 1

Ok, given your edits and my assumptions in the comments to the question, I’d probably do the following (which I think is close to what you were suggesting anyway). Note that I’m assuming that the order of processing is important but not the order of any results being produced (for that you’d need to use a sequence id on each payload item).

I suggest the following:

1. Use a queue-based mechanism to ensure the order of the execution of
   items with the same dialog id. This could be either a concurrent
   queue implementation or a JMS queue, depending on the distribution
   of your system.
2. Decide on the number of queues you need, given your total payload.
3. All items with the same dialogId must go to the same queue. Multiple
   different dialogIds can go to the same queue.
4. Identify which queue a dialogId should be assigned to using a hash
   or modulo of the id. This way, your queue will always contain the
   payload items in order for a dialogId.

5. Either:

   (a) Hang multiple worker threads off each queue to process items concurrently,
   in-sequence from the queue. This provides the highest concurrency (within the
   confines of your hardware) but you do run the risk of two items with the same
   dialog id being started in order but finished out of order (i.e. 1001_1 starts
   first but sleeps and 1001_2 starts and completes within that time).

   (b) Hang only one worker thread off each queue to process items from that queue in
   strict order one at a time. You now cut the number of threads down per queue to
   only one but, in doing so, you guarantee the order of processing for that queue
   (and all dialogIds processed on it).

   (c) As (b) but with one thread per dialog id (for all ids processed on that queue
   that can peek ahead and only process threads with that id. This guarantees the
   order and improves throughput (i.e. more threads).

   (d) As (a) with multiple threads that operate across all ids but will lock on dialog id
   to ensure processing completes in order. A lot of overhead in managing what to do
   when a dialog id is locked – start new queue? requeue?

In any case, you can always at least have one thread per queue and as many queues as is optimal for your set up. This way you can achieve some concurrency. Also, the more you can spread the dialog ids across queues, the better. Additional considerations are load balancing the queues.