mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Trustin Lee" <trus...@gmail.com>
Subject Re: Huge SessionBuffer event queue empties too slowly
Date Tue, 16 Jan 2007 01:53:40 GMT
On 1/16/07, Steven E. Harris <seh@panix.com> wrote:
> Trustin Lee <trustin@gmail.com> writes:
> > So incoming messageSent() events caused by session.write(new
> > Quote()) are not being processed until messageReceived(IoSession,
> > CmdReplicate) ends.  Writing from a separate thread is a good idea
> > here, too.
> This sounds related to my question from last week that has yet to
> provoke any response:
>   IoSession-level synchronization of ProtocolEncoder/ProtocolDecoder pair
>   http://article.gmane.org/gmane.comp.apache.directory.mina.devel/2779
> http://www.nabble.com/IoSession-level-synchronization-of-ProtocolEncoder-ProtocolDecoder-pair-tf2947470.html

Oops... Sorry for being late in responding!

Since writing that message, I've confirmed that all ByteBuffer write
> requests to SocketSessionImpls (socket-based IoSessions) get pushed
> into a queue, and are drawn out by a single worker thread to be
> written to the actual socket.
> Looking at ExecutorFilter.fireEvent(), if I'm not mistaken, no more
> than one thread will ever service a given IoSession's event
> queue. However, it's possible that one thread is writing outbound
> messages (passing down through the filter chain) while
> SocketIoProcessor's worker thread is reading and dispatching incoming
> messages (passing up through the filter chain), possibly splitting off
> to per-session worker threads via an ExecutorFilter.


If this description is accurate, can one then conclude that an
> IoFilter's messageSent() and filterWrite() methods might be called
> concurrently for a given IoSession?

Yes, exactly.

what we call human nature is actually human habit
PGP key fingerprints:
* E167 E6AF E73A CBCE EE41  4A29 544D DE48 FE95 4E7E
* B693 628E 6047 4F8F CFA4  455E 1C62 A7DC 0255 ECA6

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message