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 03:13:24 GMT
On 3/13/06, peter royal <proyal@apache.org> wrote:
>
> On Mar 12, 2006, at 9:25 PM, Trustin Lee wrote:
>
> 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.
>
>
> Is it really specific to the type of thread pool? I attached a pluggable
> implementation to http://issues.apache.org/jira/browse/DIRMINA-184 , and
> retained the ordering of events while using a ThreadPoolExecutor..
>

Yep I think so because decoder only works inside the thread pool threads.
Could you dig into the code a little bit?  I might be wrong. ;)

Oh, did you retain the event order?  That sounds very interesting.  I'll
take a look at the code.

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