Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Received-SPF: pass (nike.apache.org: domain of elecharny@gmail.com designates
 209.85.214.50 as permitted sender)
Message-ID: <4F858163.2000804@gmail.com>
Date: Wed, 11 Apr 2012 15:04:35 +0200
From: =?UTF-8?B?RW1tYW51ZWwgTMOpY2hhcm55?= <elecharny@gmail.com>
Reply-To: elecharny@apache.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
 rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: [index] OneLevelIndex removal
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi guys !

so I completely removed the OneLevelIndex from the server. The branch 
(index) has been successfully merged back into trunk, and I will now 
work on removing the SublevelIndex from the index branch.

In the process, I spent 3 days closing all the cursors that weren't 
closed after having been used. This was *BORING*. In the future, I would 
really appreciate if those who use the cursors double check that they 
have closed them.

To do that, I added some logs in every cursor constructor and every 
close() method, and matched the opens with the closes. Do'nt ask me if 
this was fun to match them... I created a small program which was able 
to do that for me, but this is not enough to know that a cursor has been 
created but not closed, we also have to know where it has been created.

I think we should add some mechanism in the server to check that 
automatically, to avoid doing it by hand (there are hundreds of tests to 
check...). One solution would be to keep a track of every cursor 
construction in a HashMap, and to remove them when the cursor is closed. 
The remaining cursors are likely not closed. The pb is that it gives no 
clue about where those cursors have been created, unless we associate a 
stackTrace to this information. Really not possible in production, but 
we might add an extended request to activate this mode, or a flag in the 
config.

If anyone has a better idea ?

Thanks !


-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com