mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Frédéric Brégier <fred.breg...@free.fr>
Subject Re: Order that data is received?
Date Wed, 02 May 2007 18:22:24 GMT
One remark, possibly erroneous, so correct me if I am wrong:
TCP ensures that packet will arrive in the same order on the server
side as they were sent by the client but then if there are threads,
nothing ensure you that they are managed in this order once MINA
has created the thread process (in the filter logic I mean).

If on the server side there are a thread pool that works on the
received packet and saying the business work could be heavy
so the use of a thread pool in the filter, you can imagine that one first 
packet
will generate one first thread and continue to work while
the second packet arrived and another new thread will start.
So, in fine, you will have two threads working at the same
time for the same connection but for two different messages/packet.
If this is OK, no problem. But if not, you might considering acknowledge
of each packet.

I have seen this using a demux io handler. One client send a first message,
generating a new thread, then send the next message (possibly a different
type of message) and generating again a new thread on the server side.
Then, sometimes (on multi processor servers) I saw the second
thread finishing its work before the first one (the business logic
was less on the second message than the first message of course).

To get the correct result, I have made two implementations :
1) Using an acknowledge of the first message when the business is done.
Advantage: I am sure that everything is done in the correct order.
Disadvantage: This is slow since every message are waiting on the client
side to the acknowledge of the previous message. The time is then following
the delay on the network side.
2) Using an ordering message and business logic in it so that the client
can send any message as it wants, and the server acknowledge the final
message, not all of them.
Advantage: Less messages are sent from the server, only the useful one (the
last one) so there is no limit according to the delay of the network.
Disadvantage: Take care about the memory aspect (all messages are send 
quickly
so received also quickly and there are much more active threads and objects 
in memory).

The second was better for my business logic.
My 2 cents on this...
If I am wrong, then I have surely done something wrong in my application.

Frederic

----- Original Message ----- 

Hi Pete,

I was really hoping that was the case, but I wanted to be absolutely
certain.

Thank you very much!  I was dreading having to take that into
consideration, re-ordering my messages would cost me more CPU cycles.

Cheers,
Richard.
--

peter royal wrote:
> On May 1, 2007, at 8:41 PM, Richard Lowe wrote:
>> Firstly, I'm using TCP and Mina 1.1.
>>
>> Let's say that my client executes the write method of
>> IoHandlerAdapter and sends 100,000 bytes ('A') to the remote server.
>>
>> My client then immediately sends another 25,000 bytes ('B') to that
>> same server with a subsequent write call.
>>
>> Will 'A' always arrive at the server before 'B' even though it
>> contains more bytes?
>
> Yes.
>
> (TCP guarantees the sending order)
>
> -pete
>
>
> --proyal@apache.org - http://fotap.org/~osi
>
>
>



Mime
View raw message