Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 67548 invoked from network); 13 Mar 2006 03:13:47 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 13 Mar 2006 03:13:47 -0000 Received: (qmail 95441 invoked by uid 500); 13 Mar 2006 03:13:47 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 95407 invoked by uid 500); 13 Mar 2006 03:13:46 -0000 Mailing-List: contact dev-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list dev@directory.apache.org Received: (qmail 95396 invoked by uid 99); 13 Mar 2006 03:13:46 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 12 Mar 2006 19:13:46 -0800 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of trustin@gmail.com designates 64.233.182.204 as permitted sender) Received: from [64.233.182.204] (HELO nproxy.gmail.com) (64.233.182.204) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 12 Mar 2006 19:13:46 -0800 Received: by nproxy.gmail.com with SMTP id k26so154105nfc for ; Sun, 12 Mar 2006 19:13:24 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=CCJjq4QIbOFXZ//xpRSQ09Qsk7MAZ3StVo5q6ZNtrtwZdXqq2L7QAzD3HlDhwklQv9mOd9gCzXlyJqm7/f5twDAg6xqe2KqCBdC4rLTHeBxIA+geXdM8G3LdwP/8G0Y44R3usdIAikbQFS3GkyPpR+t9kvQG2yVO+xsV+A7GxpE= Received: by 10.49.20.15 with SMTP id x15mr736499nfi; Sun, 12 Mar 2006 19:13:24 -0800 (PST) Received: by 10.49.19.11 with HTTP; Sun, 12 Mar 2006 19:13:24 -0800 (PST) Message-ID: <768dcb2e0603121913t13c86b2bl12f8b6c4504269fa@mail.gmail.com> Date: Mon, 13 Mar 2006 12:13:24 +0900 From: "Trustin Lee" To: "Apache Directory Developers List" 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 In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_4488_6356586.1142219604874" References: <768dcb2e0603121507o7b41977cv946b10af97e0805f@mail.gmail.com> <94765860-FFA2-41EE-B86C-C0C9A83753F3@apache.org> <768dcb2e0603121825nb57ba68r437f418aea1543f1@mail.gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N ------=_Part_4488_6356586.1142219604874 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On 3/13/06, peter royal wrote: > > On Mar 12, 2006, at 9:25 PM, Trustin Lee wrote: > > Because of datagram transport and pluggable thread pool, we have to retai= n > the synchronization. Datagram doesn't become a problem if DIRMINA-162 (h= ttp://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 LFT= P, > 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 ------=_Part_4488_6356586.1142219604874 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On 3/13/06, peter royal <proyal@apache.org> wrote:
On Mar 12, 2006, at 9:25 PM, Trustin Lee wrote:
<= blockquote type=3D"cite">
Because of datagram transport and plugga= ble thread pool, we have to retain the synchronization.  Datagram does= n'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 se= riously?'  Robert told us an ordinary TP performs 25% better than a LF= TP, but it might be just because encoding is not pooled.=20

Is it really specific to the type of thread pool? I attac= hed a pluggable implementation to  http://issues.apache.org/jira/browse/DIRMINA-184 , and retained the ord= ering of events while using a ThreadPoolExecutor.. 
<= /blockquote>

Yep I think so because decoder only works inside the t= hread 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 interest= ing.  I'll take a look at the code.

Trustin
--
w= hat we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP key fingerprints:
* E167 E6AF E7= 3A CBCE EE41  4A29 544D DE48 FE95 4E7E
* B693 628E 6047 4F8F C= FA4  455E 1C62 A7DC 0255 ECA6 ------=_Part_4488_6356586.1142219604874--