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 (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
