> feel free to ask more! I have, thanks for the offer.
> Basically, MINA was designed as a SEDA based framework (even if this > target has been lost in the meantime, somehow ...). Since then, it has > evolved a bit. My recollection of SEDA is that it had a single thread managing all socket IO (implemented with Java NIO or a C library called via JNI) and all file IO (since there is no consistent way of achieving good asynch file IO across OSs, this is _simulated_ with a thread pool, but this is an _implementation detail_). The only "real" (in the sense that it is not an implementation detail) thread pool that I recall in SEDA is the pool that fetches incoming messages in batches and processes them. I could be wrong; this is all from memory. > The internal design was done in order to decouple the concerns as much > as possible. So you have a thread handling incoming connections, N > processor, each of them having a selector, to process the incoming and > outgoing events (read and write) each processor being associated with a > thread, and as you can add an Executor filter in the chain, you can also > have N threads to handle the load (this construction is the only > remaining SEDA flavor in the framework). But then the question arises: why do you even need NIO to do this? If every accept, connect, read and write are run from separate threads, you could just issue blocking calls. Or am I not understanding your description? > All those threads are intended to offer a better scalability, but that > has still to be proven :) One of the canonical problems that SEDA was trying to solve was the "C10K" problem: having a web server capable of handling ten thousand clients simultaneously (see http://www.kegel.com/c10k.html). My recollection is that using threads for each of those clients is out of the question, in that it is not possible to have that many threads operating reliably. > But more than that, and many persons are questioning the scalability, > it's a damn simple framework when it comes to quickly design a server, > letting you to focus on what matters : the codec and the handler. > > At some point in the future, though, considering other aspects than ease > of use, we may have to tune the design to allow one user to select the > best solution. We are far from this point ... :/ Understood. > I hope I brought a bit of light in the dark :) You have, and you have also brought up new questions... Thus science progresses... > cordialement, regards, > Emmanuel Lécharny -- Gonzalo Diethelm DCV - Chile ----------------------------------------- Declaración de confidencialidad: Este Mensaje esta destinado para el uso de la o las personas o entidades a quien ha sido dirigido y puede contener información reservada y confidencial que no puede ser divulgada, difundida, ni aprovechada en forma alguna. El uso no autorizado de la información contenida en este correo podrá ser sancionado de conformidad con la ley chilena. Si usted ha recibido este correo electrónico por error, le pedimos eliminarlo junto con los archivos adjuntos y avisar inmediatamente al remitente, respondiendo este mensaje. "Before printing this e-mail think if is really necesary". Disclosure: This Message is to be used by the individual, individuals or entities that it is addressed to and may include private and confidential information that may not be disclosed, made public nor used in any way at all. Unauthorized use of the information in this electronic mail message may be subject to the penalties set forth by Chilean law. If you have received this electronic mail message in error, we ask you to destroy the message and its attached file(s) and to immediately notify the sender by answering this message.
