mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@gmail.com>
Subject Re: [MINA 3] Session write queue
Date Mon, 18 Apr 2011 08:26:42 GMT
On 4/18/11 10:01 AM, Steve Ulrich wrote:
> Hi!
> I'm sceptical about it. Maybe you could design it in a way, that the IoProcessor is replaceable,
so one could test the behaviour.
And this is why I posted my suggestion on the mailing list :) My idea 
might well be totally off base.
> Cons:
> * Imagine a bunch of smaller write requests per session. Currently an IoProcessor at
least have a chance to optimize the writes by flushing all data of a single session at once,
thus minimizing the TCP/IP-packages. Under heavy load, a single queue will be stuffed with
a lot of write requests from different sessions and the IoProcesser will write each one in
the order they are written to the queue, causing a higher fragmentation.
Fair enough. But we can mitigate this risk on the IoProcessor too, by 
pulling out of the queue all the messages for a session, until the 
socket can't accept any more writing. Something like :

while () {
     WriteReqest message = queue.get();
     Session session = message.getSession();
     Channel channel = session.getChannel();

     while ( channel is ready for write) do {
         channel.write( message );
         message = queue.get( session );

Does it sounds crazy ?
> * With this the IoProcessor will be constantly switching between sessions, checking the
state of the session, etc.
See above
> * An additional cpu cost will be the increased synchronization efforts inside the queue...
There will be more threads, writing to the same queue at the same time.
No, because the IoProcessor is using one single thread.
> The memory is bought with costs at network throughput and processor cycles.
> What do you mean by "it's not a free data structure in term of memory consumption"?
> As far as I understand, a linked queue contains only elements, if there is something
stored in there.
Hmmmm, whatever the queues use, it's irrelevant. There is no reason that 
we don't use the same in the IoProcessor queue, as we have the exact 
same number of elements in this queue than the number of all the 
elements used in all the Session queues.

My expalanition was just plain silly. Thanks for pointing this out.
> Pro:
> * Behaviour may be more fair.
> Write-Throttling may be done by a filter. IMHO It's the better place anyway.

> So you may have the option to place the write throttle at the start of your queue and
save processor speed.

Yes. The problem is to deal with the throttle in a filter, which is not 
totally obvious.

Thanks !

Emmanuel L├ęcharny

View raw message