From dev-return-32624-apmail-directory-dev-archive=directory.apache.org@directory.apache.org Fri Feb 05 02:04:23 2010 Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 5640 invoked from network); 5 Feb 2010 02:04:23 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 5 Feb 2010 02:04:23 -0000 Received: (qmail 89495 invoked by uid 500); 5 Feb 2010 02:04:23 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 89411 invoked by uid 500); 5 Feb 2010 02:04:23 -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 89400 invoked by uid 99); 5 Feb 2010 02:04:23 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 05 Feb 2010 02:04:23 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of ayyagarikiran@gmail.com designates 209.85.216.194 as permitted sender) Received: from [209.85.216.194] (HELO mail-px0-f194.google.com) (209.85.216.194) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 05 Feb 2010 02:04:15 +0000 Received: by pxi32 with SMTP id 32so1595634pxi.15 for ; Thu, 04 Feb 2010 18:03:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=K1SSKoQMUhVLv8QOhspY+uUHH6M2YGFRHG3Vi+VGEuU=; b=erGsXbP6N91l87AL08IQcJ7FtdkBuIIl8U3bA28kifohvaYGwLhLtf5ftw2gam0fcw qujOm/Kd1vPJUtFxRT5jkYj8dpEcqp0LFtt9bb2Mah7fArrHPO1ZA/d1NWraT5B+q0Gl figCO2/6Qnqph/d/DNz0hfV3JbFAoSekRAYpo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=hGDcNBWE9EKo54c0c1bWmZf9o0OewAmZTCgBE6GDMSCDR0n/k8k5TW8sLhpye4X0ev sXdOwameYaL5LpknqwC258BxLX9ugHEnMa0fjJCaf5pd9/kfgygLxt7ktpo0OtmdKLQL 2SR8XUXncWckhl+vaTobpgrDh/vulIJd3pnxg= MIME-Version: 1.0 Received: by 10.141.107.9 with SMTP id j9mr1341053rvm.200.1265335433935; Thu, 04 Feb 2010 18:03:53 -0800 (PST) In-Reply-To: <4B6AF116.1090706@gmail.com> References: <4B6AF116.1090706@gmail.com> Date: Fri, 5 Feb 2010 07:33:53 +0530 Message-ID: <1cbc90c11002041803lb2ddf58nec873e52ab3a47cd@mail.gmail.com> Subject: Re: About message response handling in the API From: Kiran Ayyagari To: Apache Directory Developers List , elecharny@apache.org Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Checked: Checked by ClamAV on apache.org > I think we have a huge problem in the current ldap-api implementation. > Currently, when we send a request, we cretae an associated Future in which > we store a response queue we have created to store the response when it will > arrive. So far, so good. > > The problem is that we need to associate an incoming response to the Future > it is targeting. To do so we have a FutureMap, and as every > response has the same MessageId than the associated request, we can easily > find which request a response is associated to. > > So when we get a response, we extract its messageId, do a lookup in the > futureMap and get back the Future, then we update the queue with the > response. The client which is doing a future.get() will then get its > response. > > Now, we could perfectly unbind, and rebind immediately. What happens ? The > session is then closed, and all responses we are waiting for will be > discarded. First big bug here : we don't cleanup the futureMap. > > Another case : instead of unbinding, we send an abandon request. It seems > that we clean up the futureMap. > > Last, not least, we can re-bind. In this case, the connection is not reset, > but we start with a new MessageId, starting at 1. And we have another bug > here : we don't cleanup the futureMap. > > So we have to check all those cases and fix them. +1 right now I don't have access to the code, will take a look at these issues, and am sure as you said during unbind only the futureMap is cleaned atm thanks Emmanuel Kiran Ayyagari