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
