David Rosenstrauch wrote:
David Rosenstrauch wrote:
David Rosenstrauch wrote:
Still, wouldn't it also make sense to have a thread pool on writes
as well? That way once a message has been processed, the
reader/processor thread can just dump the response message into a
queue for output, thereby freeing up the reader thread to process
new incoming messages. Seems like in theory you could handle a lot
more message throughput by decoupling message reading from writing
like this.
Am I offbase in my assumptions here?
Thanks,
DR
Hmmm .... answering my own question a bit here, but:
The MINA javadocs state:
IoSession.write(Object message):
"Writes the specified message to remote peer. This operation is
asynchronous; IoHandler.messageSent(IoSession,Object) will be
invoked when the message is actually sent to remote peer. You can
also wait for the returned WriteFuture if you want to wait for the
message actually written."
So then this is already happening in a separate thread than the
reader, and so there's no need for a separate writer thread pool?
Confused ....
DR
Actually, I went digging in the code tonight ... and it looks like
even if you add an ExecutorFilter with the intention of having socket
writes occur in a separate thread, MINA won't let that happen.
Apparently as per the code in DefaultIOFilterChain.HeadFilter, all
writes are getting done by the filter at the head of the chain. The
head filter puts the write request into a request queue, and the
IoProcessor executes the request in one of its threads, and not in one
of the executor filter's threads.
So looks like adding a thread pool for writes is a completely useless
thing to do.
I guess I understand why the code is written this way - all IO should
get done in one of the IOProcessor threads. But it does seem a bit
confusing and misleading for it to be allowable to add an executor
filter which will accomplish nothing.
DR
DR
MINA uses IoProcessor to handle incoming requests. When you instanciate
the server, more than one of these objects are created, so you can
process more than one request at the same time. Each of those
IoProcessor has its own selector, but then, you should consider that the
processing of one request is done in one single thread, ie the
IoProcessor thread. More than that, each session is associated with a
single IoProcessor object, so it can't be processed by another
IoProcessor instance.
That being said, you may need to decouple the processing from the IO
handling. For instance, assuming that you may have a lot of small and
fast requests to process, plus from time to time one big expensive and
CPU consuming request, you may want to free the IoProcessor as fast as
possible for the small requests to be processed quickly. This is what
the Executor filter is good for. When you add such a filter in the
chain, it simply enqueue all the requests and ask a thread pool to
process them, letting the IoProcessor doing its job quickly.
In any case, when the request has been processed, the response is
written into a queue by the executor thread, AFAICT. As the write is
done at the end of the processing (in your IoHanlder implementation),
it's still traversing the chain using the thread selected by the
executor filter, up to the point the request is written to the queue.
Then the execution stack is unfold. It seems a bit complex, and it might
have been a bit better to separate the incoming and outgoing chains, but
at least, it does the job.
I hope I brought some faint light about the way MINA is working from the
inside out. Just tell me if it's enough for waht you need.
Thanks !
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
