From dev-return-40733-apmail-directory-dev-archive=directory.apache.org@directory.apache.org Wed Apr 11 20:38:44 2012
Return-Path:
X-Original-To: apmail-directory-dev-archive@www.apache.org
Delivered-To: apmail-directory-dev-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
by minotaur.apache.org (Postfix) with SMTP id F10919F7C
for ; Wed, 11 Apr 2012 20:38:43 +0000 (UTC)
Received: (qmail 58624 invoked by uid 500); 11 Apr 2012 20:38:43 -0000
Delivered-To: apmail-directory-dev-archive@directory.apache.org
Received: (qmail 58593 invoked by uid 500); 11 Apr 2012 20:38:43 -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 58586 invoked by uid 99); 11 Apr 2012 20:38:43 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 11 Apr 2012 20:38:43 +0000
X-ASF-Spam-Status: No, hits=1.5 required=5.0
tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: domain of akarasulu@gmail.com designates 74.125.82.44 as permitted sender)
Received: from [74.125.82.44] (HELO mail-wg0-f44.google.com) (74.125.82.44)
by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 11 Apr 2012 20:38:36 +0000
Received: by wgbdr13 with SMTP id dr13so1284315wgb.1
for ; Wed, 11 Apr 2012 13:38:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20120113;
h=mime-version:sender:in-reply-to:references:date
:x-google-sender-auth:message-id:subject:from:to:content-type;
bh=wDoQRJbKTdh6gPu03Y+4ow0qmpvR+5hDw4aI4yYbubw=;
b=E+wp5egxsQRK1lqCN1AEVoSuleXCU9f7CV0Je909eUH+/pt8GC65PHByiz15GezEih
7Zl5elJLjzvnw3moWqT21YiL9JaIUv4o96gZ/GSpQ4juNpMhmba6tZv+ZscJ1AZRL++G
AlqPvvcZteiGX9SaiwbiXPoQ7AXoYWtejZHM4ZDr3CATu7i1WkGgg2+Xe4TlJCpVpCTa
4J9mi1yje56QIWWQ9dpfPmK+ZndEh6y0rCCAr5q5nJXgi+F9vTnCBM5dXdPiIfUlCq3z
JPog4VEPgmfncIo7N0vgIN0xn1ki/R1J5NMBobf1JuYbh8CsnSvM1QJfBa9bLqnR5J94
Z9rg==
MIME-Version: 1.0
Received: by 10.180.95.129 with SMTP id dk1mr22449529wib.3.1334176696433; Wed,
11 Apr 2012 13:38:16 -0700 (PDT)
Sender: akarasulu@gmail.com
Received: by 10.180.126.97 with HTTP; Wed, 11 Apr 2012 13:38:16 -0700 (PDT)
In-Reply-To: <4F858163.2000804@gmail.com>
References: <4F858163.2000804@gmail.com>
Date: Wed, 11 Apr 2012 23:38:16 +0300
X-Google-Sender-Auth: I3EOqvCLhFrIG92Tn9Q6qK-PShg
Message-ID:
Subject: Re: [index] OneLevelIndex removal
From: Alex Karasulu
To: Apache Directory Developers List , elecharny@apache.org
Content-Type: multipart/alternative; boundary=f46d0444ee2d0efbec04bd6d384c
--f46d0444ee2d0efbec04bd6d384c
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Wed, Apr 11, 2012 at 4:04 PM, Emmanuel L=E9charny w=
rote:
> 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 close=
d
> 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 close=
d
> 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 th=
is
> 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 create=
d
> 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.
It would be nice to have a Cursor monitor that every opened Cursor
registers with but this needs to happen automatically. Then when out of the
creation scope the Cursor is expected to be closed and if not this is
handled automatically. However does creation scope work well since
sometimes we create Cursors and pass them up?
This sounds like something that can be handled nicely using an aspect
oriented solution. Now these things are heavy if you use AspectJ or
something like that but other simpler solutions exist to bytecode splice
compiled code to automatically handle these things. Maybe our past
experiences with Aspects might make us reconsider.
> 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 ?
>
>
An aspect oriented solution might work well here.
> Thanks !
>
>
> --
> Regards,
> Cordialement,
> Emmanuel L=E9charny
> www.iktek.com
>
>
--=20
Best Regards,
-- Alex
--f46d0444ee2d0efbec04bd6d384c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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

In the process, I spent 3 days closing all the cursors that weren't clo=
sed after having been used. This was *BORING*. In the future, I would reall=
y appreciate if those who use the cursors double check that they have close=
d 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 wa=
s 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 n=
ot closed, we also have to know where it has been created.

I think we should add some mechanism in the server to check that automatica=
lly, to avoid doing it by hand (there are hundreds of tests to check...). O=
ne solution would be to keep a track of every cursor construction in a Hash=
Map, and to remove them when the cursor is closed. The remaining cursors ar=
e likely not closed.

It would be nice to have a Cursor monitor that every op=
ened Cursor registers with but this needs to happen automatically. Then whe=
n out of the creation scope the Cursor is expected to be closed and if not =
this is handled automatically. However does creation scope work well since =
sometimes we create Cursors and pass them up?=A0

This sounds like something that can be handled nicely u=
sing an aspect oriented solution. Now these things are heavy if you use Asp=
ectJ or something like that but other simpler solutions exist to bytecode s=
plice compiled code to automatically handle these things. Maybe our past ex=
periences with Aspects might make us reconsider.

=A0

The pb is that it gives no clu=
e about where those cursors have been created, unless we associate a stackT=
race to this information. Really not possible in production, but we might a=
dd an extended request to activate this mode, or a flag in the config.