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.
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. * With this the IoProcessor will be constantly switching between sessions, checking the state of the session, etc. * 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. 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. 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. regards Steve Emmanuel Lecharny [mailto:[email protected]] wrote: Hi, in MINA 2, each session has a write queue. It sounds a bit spurious, as a session is associated with a IoProcessor in charge of writing data. What if we remove this write queue, to move to to the IoProcessor ? Let's analyze the issues we will face and advantages we will get if we change this. o We will spare a queue for each session, thus consuming less memory. The WriteQueue is a ConcurrentLinkedQueue, and it's not a free data structure in term of memory consumption. o Throttling will become more difficult to manage, because we won't be able to check if the number of messages or bytes has reached its limit in the IoProcessor. o If the write queue is associated with the session, suspending write will just be a matter to forbid the IoProcessor to read the queue. If we move the queue to the IoProcessor, we will have to check for each message present in the queue that its associated session is forbidding the write If you see some more potential issues, -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com -------------------------------------------------------------------------- PROEMION GmbH Steve Ulrich IT Development (IT/DEV) Donaustrasse 14 D-36043 Fulda, Germany Phone +49 (0) 661 9490-601 Fax +49 (0) 661 9490-333 http://www.proemion.com/ mailto:[email protected] Geschäftsführer: Dipl. Ing. Robert Michaelides Amtsgericht-Registergericht-Fulda: 5 HRB 1867 -------------------------------------------------------------------------- E-mail and any attachments may be confidential. If you have received this E-mail and you are not a named addressee, please inform the sender immediately by E-mail and then delete this E-mail from your system. If you are not a named addressee, you may not use, disclose, distribute, copy or print this E-mail. Addressees should scan this E-mail and any attachments for viruses. No representation or warranty is made as to the absence of viruses in this E-mail or any of its attachments. AKTUELLES http://www.rmcan.de/ NEWS http://www.rmcan.com/
