mina-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lécharny <elecha...@gmail.com>
Subject Re: Thread priorities between request and response
Date Wed, 12 Sep 2012 13:09:32 GMT
Le 9/12/12 8:36 AM, Antonio Rodriges a écrit :
> Hello, Brendan & Emmanuel,
> Sorry for joining the discussion too late. I am just interested on the
> details since we have also Mina-based application with high read/write
> rates.
> Our clients issue queries and wait for respose. A client does not
> issue new query until it receives a respose. We use single session for
> a multithreaded client.
> Emmanuel, as far I understood, IoProcessor loops until it has
> something to read for a session.
Not exactly. IoProcessor does a select(), which is blocking (and consume 
no CPU at all) until some socket becomes active (either ready to read or 
write, or newly connected).

> When it finishes, it starts writing
> and writes until it has something to write?
For each session that has been activated, it process the read, and when 
done, process the write. That means that, if we have, say, 10 activated 
sessions, we will do 10 read/write actions (we may not write anything 

Also keep in mind that a session can write but not read - for instance 
if we have a big message to send but we weren't able to write all the 
data in the previous loop - or read and not write.

> Brendan, do your clients interact with the server and do not wait for
> a response? Did you try two separate sessions, one for incoming
> messages and another for outgoing ones?
> Seems like we must also investigate the possibility of separating
> in/out message queues.
> Also, when using ExecutorFilter and several IoProcessors for both in
> and out queues, we, theoretically, may additionally achive speedup due
> to the load disribution. This is when only read first and only write
> after that sequence takes place inside a single session (i.e. for
> session 1 we can read while for session 2 we can write concurrently
> with different IoProcessors).
> Emmanuel, is it true: IoProcessor will not forward on to the next
> outgoing message until its buffer will not be comletely written to the
> network or system buffer or smth else?
No. Reads and writes are not correlated. When you do a session.write() 
in your handler, at least two messages are written in a write queue. The 
IoProcessor will peek messages from this write queue and write them in 
the socket until the socket is full, and will start again writing when 
the socket is OP_WRITE ready. You may receive many messages in the mean time

(FTR, we write two messages for a simple reason - and it's a trick - : 
the first message contains the data to be sent, the second message is 
empty and is just used to notify the stat counter that a message has 
been sent. The client will *never* receive this second message. We have 
to do that because those messages contains byte[], and we have no idea 
about their boundaries)
> If so, having N big responses that must go through the same sessiion
> and large enough buffer, and, say 40 ms to transfer each, the first
> client will receive the response in (approx) 40 ms, the next in 80 ms,
> 3rd in 120 ms, etc.
If you have more than one client, then you will have more than one 
session. Your numbers are not what you'll experiment.
> Is it correct? If so, is there a way to have several threads writing
> to the same session concurrently (since in any way we have multicore
> CPUs)?
Again, if you have many clients connected to the server, then you will 
have as many session. A session is used for every socket, and a client - 
server connection will use one socket. So if you have more than one 
client, you'll have more than one socket, thus more than one session.

Emmanuel Lécharny

View raw message