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
|