directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Trustin Lee" <trus...@gmail.com>
Subject Re: svn commit: r385254 - in /directory/trunks/mina/core/src/main/java/org/apache/mina/filter/codec: ProtocolCodecFactory.java ProtocolCodecFilter.java demux/DemuxingProtocolCodecFactory.java demux/MessageDecoderFactory.java demux/MessageEncoderFacto
Date Mon, 13 Mar 2006 02:25:44 GMT
On 3/13/06, peter royal <proyal@apache.org> 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...
>
>
> http://svn.apache.org/viewcvs.cgi/directory/trunks/mina/core/src/main/java/org/apache/mina/filter/codec/ProtocolCodecFilter.java?rev=385254&view=markup
>
> 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 (
http://issues.apache.org/jira/browse/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.

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

Mime
View raw message