Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 61275 invoked from network); 12 Oct 2005 16:44:32 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 12 Oct 2005 16:44:32 -0000 Received: (qmail 96927 invoked by uid 500); 12 Oct 2005 16:44:31 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 96883 invoked by uid 500); 12 Oct 2005 16:44:31 -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 96871 invoked by uid 99); 12 Oct 2005 16:44:30 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 12 Oct 2005 09:44:30 -0700 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.184.201 as permitted sender) Received: from [64.233.184.201] (HELO wproxy.gmail.com) (64.233.184.201) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 12 Oct 2005 09:44:32 -0700 Received: by wproxy.gmail.com with SMTP id i21so51082wra for ; Wed, 12 Oct 2005 09:44:09 -0700 (PDT) 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=tCgm3aBAp0gGVsDMCEB99NUyn1WWo/0k129wsAMmAOnyBjQaG26n4QasFCEIeSMWNusMsQivXk79jt9hVMCQmqWOEm9C8Ronqi2+NzAz2p2JPMhxzjtSQOyMASAgAlB/EEniedQ6ueB0ifQIaBh11RKsjZAixBsZ+kjb6z8tIl8= Received: by 10.54.112.17 with SMTP id k17mr209962wrc; Wed, 12 Oct 2005 09:44:09 -0700 (PDT) Received: by 10.54.71.11 with HTTP; Wed, 12 Oct 2005 09:44:09 -0700 (PDT) Message-ID: <768dcb2e0510120944o48d0fb36x@mail.gmail.com> Date: Thu, 13 Oct 2005 01:44:09 +0900 From: Trustin Lee To: Apache Directory Developers List Subject: Re: [Mina] Best to have prioritary messages In-Reply-To: <20051011090121.z5hu336mwogs4g88@webmail.daune-consult.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_15440_193176.1129135449532" References: <20051011090121.z5hu336mwogs4g88@webmail.daune-consult.com> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N ------=_Part_15440_193176.1129135449532 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 2005/10/11, daune.jf@daune-consult.com : > > I don't want to reorder messages received per session. > Instead, when my server 'elects' the next session for processing, I want it > to > first promote the sessions having a message X older than (Y-Z) seconds. I see. I have checked BaseThreadPool, and if I understand well, I would need > to change > 'fetchBuffer' so that it first chooses SessionBuffer containing such > message. > > Is that correct? Yes, you're correct. You'll have to maintain the number of the messages of that type so you don't waste the time while iterating the buffer. I am not sure as the difference between readySessionBuffers and > busySessionBuffers does not appear clearly to me (why is a BufferSession > added > to busySessionBuffers in fireEvent?) busySessionBuffers contains the SessionBuffers which have any events to fir= e in them. readySessionBuffers contains the SessionBuffers which are waiting for the leader thread to process them. So a SessionBuffer is removed from readySessionBuffers when the leader thread takes it, but not from busySessionBuffers to prevent the same SessionBuffer from being added to readySessionBuffers and busySessionBuffers because it will cause severe synchronization issue. BTW the names are really confusing. I had to spend some time to explain thi= s to you. I'd better change them to more clear ones. Any suggestions? :) HTH, Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ ------=_Part_15440_193176.1129135449532 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
2005/10/11, daune.jf@daune-consult.com <daune.jf@daune-consult.com>: I don't want to reorder messages received per session.
Instead, when my serv= er 'elects' the next session for processing, I want it to
first promote the sessions having a message X older than (Y-Z) seconds.=

I see.

I have checked BaseThreadPool, and if I understand well, I would need
to= change
'fetchBuffer' so that it first chooses SessionBuffer containing = such message.

Is that correct?

Yes, you're corr= ect.  You'll have to maintain the number of the messages of that type = so you don't waste the time while iterating the buffer.

I a= m not sure as the difference between readySessionBuffers and
busySession= Buffers does not appear clearly to me (why is a BufferSession added
to busySessionBuffers in fireEvent?)

busySessionBu= ffers contains the SessionBuffers which have any events to fire in them.&nb= sp; readySessionBuffers contains the SessionBuffers which are waiting for t= he leader thread to process them.  So a SessionBuffer is removed from = readySessionBuffers when the leader thread takes it, but not from busySessi= onBuffers to prevent the same SessionBuffer from being added to readySessio= nBuffers and busySessionBuffers because it will cause severe synchronizatio= n issue.

BTW the names are really confusing.  I had to spend some time = to explain this to you. I'd better change them to more clear ones.  An= y suggestions?  :)

HTH,
Trustin
--
what w= e call human nature is actually human habit
--
http://gleamynode.net/ ------=_Part_15440_193176.1129135449532--