Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I want to write a multithreaded server application which is able to process requests in a multithreaded fashion while keeping up execution order of incoming requests of the same client.

For example if client A sends a message M1 and then a message M2 the muiltithreaded server must process these requests in exactly the same order, first M1 and then M2. However, there is no guarantee that threads that process these incoming requests do process these messages in the same order.

For example, thread T1 consumes message M1, thread T2 consumes message M2 and completes processing the message and is able to accept further messages before T1 has finished it's job.

After a message has been processed the result will be passed to some other process for further processing (of which only one exists in the whole computation), this process will schedule sending a response to the client.

These mutliple threads do only exist for the purpose of preprocessing data for some other process. This particular problem sounds like a problem with pipeline characteristics, first M1, then M2, then M3, etc. However, I wanted to parallalize as much as possible to achieve a higher number of communication cycles between the server and the clients.

What architecture / pattern / technique is well suited for such a task?

share|improve this question

migrated from stackoverflow.com Jan 16 '13 at 16:25

This question came from our site for professional and enthusiast programmers.

    
Sounds like a simple message queue with a timestamp on each message will solve your problem? –  Zolomon Jan 16 '13 at 18:05
    
@Zolomon: What if the items aren't received in timestamp order? Or what if they're received at roughly the same time and they take non-trivial amounts of time to process, how do you know to wait on M2 while M1 is computing, and process unrelated operations on other threads? –  Steve Evers Jan 16 '13 at 21:20
    
nono, the messages will be received ordered from the same client due to TCP, however, I don't see how a timestamp on a queue could guarantee ordered processing of requests from the same client when multiple threads process those requests. –  xSNRG Jan 17 '13 at 8:19
1  
It seems to me that if M1 and M2 must be processed sequentially, then either the caller should wait to send M2 until M1 is done, or alternatively a single message saying "M1-then-M2" should be sent (and processed by a single thread). –  AakashM Jan 17 '13 at 9:41
add comment

2 Answers

up vote 4 down vote accepted

One name for this kind of requirement is "Unit of Order".

For example, in Weblogic JMS, it provide such feature that, conceptually, you can put an UOO identifier with your message when you are putting message to queue. Weblogic JMS will guarantee that messages of same UOO being processed in chronological order. However, messages under different UOOs can be processed in parallel.

It all depends on what platform or technology you are going to implement it, which I believe there are a lot of way to achieve similar effect.

share|improve this answer
add comment

As someone already mentioned in the comments you could use a simple message queue. When a message is sent all you do is add it to the queue. You then have an asynchronously running "Listener" or "Consumer" which simply processes every message retrieved from the queue one at a time. Even though the server is multi-threaded the Listener/Consumer can be single threaded (though you have the option of using multiple when order is not important).

Edit: As pointed out by one of the comments below this will only work if processing prior to adding to the queue is instantaneous. The idea behind the separation is also to move all your logic and processing to the Listener/Consumer and not keep it in the multi-threaded portion of your code.

share|improve this answer
    
-1: This only works if the operations are virtually instantaneous. –  Steve Evers Jan 16 '13 at 21:19
    
@SnOrfus Do you mean if the process of adding to the queue is instantaneous or do you mean if the process done prior to adding it to the queue is instantaneous? The former should be handled by whatever queue technology one chooses to use. It should be atomic at least. As for the latter, you are correct. I will edit my answer to specify this assumption. –  Asaf Jan 16 '13 at 21:29
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.