directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Trustin Lee" <>
Subject Re: svn commit: r385254 - in /directory/trunks/mina/core/src/main/java/org/apache/mina/filter/codec: demux/ demux/ demux/MessageEncoderFacto
Date Mon, 13 Mar 2006 02:25:44 GMT
On 3/13/06, peter royal <> wrote:
> t depends on the implementation of codec.  Some codec might be stateless
> so they don't need any synchronization.  Of course, a codec factory usually
> returns a new instance.  It's a user's choice.
> No, regardless of codec implementation...
> look in messageReceived.. it synchronizes on decoder, prior to doing
> decoder.decode. So if you have a ProtocolDecoder that is stateless that
> could be shared, you will not be able to decode multiple messages in
> parallel.

Ah... now I remember! :D

Because of datagram transport and pluggable thread pool, we have to retain
the synchronization.  Datagram doesn't become a problem if DIRMINA-162 ( is resolved.  WRT
non-leader-followers thread pool, it apparently is a problem.

The question would be 'do we really need pluggable thread pool?' or 'does an
ordinary thread pool outperform a leader-followers thread pool seriously?'
Robert told us an ordinary TP performs 25% better than a LFTP, but it might
be just because encoding is not pooled.

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

View raw message