Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 25657 invoked from network); 19 Aug 2008 15:20:36 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 19 Aug 2008 15:20:36 -0000 Received: (qmail 96231 invoked by uid 500); 19 Aug 2008 15:20:34 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 96203 invoked by uid 500); 19 Aug 2008 15:20: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 96192 invoked by uid 99); 19 Aug 2008 15:20:34 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 19 Aug 2008 08:20:34 -0700 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 19 Aug 2008 15:19:45 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id DE453234C1C0 for ; Tue, 19 Aug 2008 08:19:44 -0700 (PDT) Message-ID: <948218065.1219159184909.JavaMail.jira@brutus> Date: Tue, 19 Aug 2008 08:19:44 -0700 (PDT) From: "Alex Karasulu (JIRA)" To: dev@directory.apache.org Subject: [jira] Commented: (DIRSERVER-1212) Size time limits on SearchControls broken in core-jndi In-Reply-To: <147992922.1217368771629.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/DIRSERVER-1212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12623698#action_12623698 ] Alex Karasulu commented on DIRSERVER-1212: ------------------------------------------ The problem is we may be in an index scan for some time while conducting the search. For example a SubstringCursor on ou=*foo might scan the entire ou index looking for a match when the cursor.first() method is called. The partition will not be able to intervene to stop this scan if the time limits are up. The reason for this is because in cursor.first() you're basically stuck in a loop that is going through the index and checking for matches based on the index. To get out of this loop in time you need the loop in the Cursor to check a variable to see if it should stop or if it has been closed() or canceled(). Does this make more sense? > Size time limits on SearchControls broken in core-jndi > ------------------------------------------------------ > > Key: DIRSERVER-1212 > URL: https://issues.apache.org/jira/browse/DIRSERVER-1212 > Project: Directory ApacheDS > Issue Type: Bug > Components: core > Reporter: Alex Karasulu > Assignee: Alex Karasulu > Priority: Blocker > Fix For: 1.5.4 > > > I commented out some tests in SearchIT.java in core-integ that rely on the correct operation of search size and time limits through paramters in a SearchControls object. This is not working any longer. Fix it and remove @Ignore tags. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.