Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 15896 invoked from network); 20 Jul 2005 01:13:35 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 20 Jul 2005 01:13:35 -0000 Received: (qmail 30013 invoked by uid 500); 20 Jul 2005 01:13:34 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 29958 invoked by uid 500); 20 Jul 2005 01:13:34 -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 29945 invoked by uid 99); 20 Jul 2005 01:13:33 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 19 Jul 2005 18:13:33 -0700 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=HTML_20_30,HTML_MESSAGE,RCVD_BY_IP,SPF_HELO_PASS,SPF_PASS,URIBL_SBL X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of trustin@gmail.com designates 64.233.184.207 as permitted sender) Received: from [64.233.184.207] (HELO wproxy.gmail.com) (64.233.184.207) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 19 Jul 2005 18:13:29 -0700 Received: by wproxy.gmail.com with SMTP id 50so461008wri for ; Tue, 19 Jul 2005 18:13:32 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:references; b=qWGvCqINbtDjNZNpp1gdk+PmUOlNfDLMjj2MvbsMgsmJjis18ezVaRuQ77SfC8/Cgv3xfmyv4IwsimW/z4/knCQH0jtMNDpW4xvAThrmP706+7XbnZ8O9bMvtSQjx8P3hryqqYMxRCK8FW7WGQS/13zKROEKRED4uGXk2FZu9kw= Received: by 10.54.52.58 with SMTP id z58mr946863wrz; Tue, 19 Jul 2005 18:12:00 -0700 (PDT) Received: by 10.54.72.4 with HTTP; Tue, 19 Jul 2005 18:12:00 -0700 (PDT) Message-ID: <768dcb2e050719181272acddcc@mail.gmail.com> Date: Wed, 20 Jul 2005 10:12:00 +0900 From: Trustin Lee Reply-To: Trustin Lee To: Apache Directory Developers List , adb@pobox.com Subject: Re: Suggestions on implementing timeouts? In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_6925_4590021.1121821920653" References: <768dcb2e05071817451372926f@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_6925_4590021.1121821920653 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Ah, I see. I implemented that when I was working for a telco company. You= =20 can simply use java.util.Timer. Just schedule timeout TimerTasks for each= =20 messages. Timer will automatically call your TimerTask.run() so that you ca= n=20 process timeout event. Of course you'll have to cancel the task whenever yo= u=20 get a response. I guess this approach doesn't have much overload comparing to the time take= n=20 by transactions. I have been using this techinique for sending about 30 SMS= s=20 a second. Trustin 2005/7/20, Alex Burmester : >=20 > My server has to keep incomming connections open to a third party > and route multiple messages over the same channel using transaction ids > to keep track of which messages are outstanding. I need a way to time out > these transactions. Currently every half second I scan my outstanding > message queues and remove any messages that are older than the timeout. M= y > issue with this is that the cleanup method has to lock the whole complex > datastructure of connections and outstanding messages during the scan. > Doesn't seem to be a problem yet but I'm concerned that under higher load= =20 > it > will become the main bottleneck. I was thinking about putting in an event > queue and firing timeout events for each message but I'm not sure if the= =20 > overhead > of registering and deregistering each timeout event for each successful > message is worth it. Just wondering if there is a pattern that I'm not > thinking of that gets around these issues. >=20 Trustin --=20 what we call human nature is actually human habit -- http://gleamynode.net/ ------=_Part_6925_4590021.1121821920653 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Ah, I see.  I implemented that when I was working for a telco company.  You can simply use java.util.Timer.  Just schedule timeout TimerTasks for each messages.  Timer will automatically call your TimerTask.run() so that you can process timeout event.  Of course you'll have to cancel the task whenever you get a response.

I guess this approach doesn't have much overload comparing to the time taken by transactions.  I have been using this techinique for sending about 30 SMSs a second.

Trustin

2005/7/20, Alex Burmester <adb@plushpix.com>:
My server has to keep incomming connections open to a third party
and ro= ute multiple messages over the same channel using transaction ids
to kee= p track of which messages are outstanding.  I need a way to time = out
these transactions.  Currently every half second I scan my outsta= nding
message queues and remove any messages that are older than the tim= eout. My
issue with this is that the cleanup method has to lock the whol= e complex
datastructure of connections and outstanding messages during the scan.<= br>Doesn't seem to be a problem yet but I'm concerned that under higher loa= d it
will become the main bottleneck.  I was thinking about pu= tting in an event
queue and firing timeout events for each message but I'm not sure if th= e overhead
of registering and deregistering each timeout event for each = successful
message is worth it.  Just wondering if there is a = pattern that I'm not
thinking of that gets around these issues.

Trustin
--
what we call human nature is actually human habit
--http://gleamynode.net/ ------=_Part_6925_4590021.1121821920653--