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 (athena.apache.org: domain of elecharny@gmail.com
 designates 66.249.82.237 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=dyBZz7AtWayNKQWuGyV7GlmDQjG4AH2F5ATcSu23/rs+mZBJH7V/06WJn/UCzia2UjIAWmr8azD2XYyXGZwi+Cys1XfTOFIcuPYQEhVyl8S5CM/d8wnhET8ZyFTd0puggWcVlvOSqj4mMh9H64eZYqyL/jSixwWOA+c5PU8L9YU=
Message-ID: <d45b08f00710100918q6230723v6d3fe1c6460cfc95@mail.gmail.com>
Date: Wed, 10 Oct 2007 18:18:39 +0200
From: "Emmanuel Lecharny" <elecharny@gmail.com>
Reply-To: elecharny@iktek.com
To: "Apache Directory Developers List" <dev@directory.apache.org>
Subject: Re: [ChangeLog] Some Q about initialization
In-Reply-To: <2C0FB1B7-CD5E-4409-91FE-704F0EB30168@yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <d45b08f00710100546k72fc95c6md815bc2eb1df4c29@mail.gmail.com>
	 <2C0FB1B7-CD5E-4409-91FE-704F0EB30168@yahoo.com>

On 10/10/07, David Jencks <david_jencks@yahoo.com> wrote:
>
> On Oct 10, 2007, at 5:46 AM, Emmanuel Lecharny wrote:
>
> > Hi,
> >
> > I was just wondering if we should not be able to initialize the logger
> > dynamically ? Using an extended operation to start or stop the logger
> > seems appropriate.
>
> What is the use case for turning it on and off while the server is
> running?

Sometime you want to debug a live server, but you don't want to stop
it and restart it. Not sure that it's a good idea though... (It could
have saved me hours in the past, when I had to wait until 3 am to be
able to stop and restart a production server (WebSphere) just to
activate some logs and to do the reverse operation the night after to
desactivate the logs, and one more day to analyze 4.5 Gb of logs ;)

Usually when you introduce runtime configurability like
> this you need to either synchronize something on the runtime path or
> introduce a volatile to assure that the component is using completely
> initialized and configured objects, and this can easily add up in
> speed costs.

Nothing seems to be free those days ;) Yes, you are right, we will
have to synchronize the flag which set the service. Does it cost a lot
? If we consider that the server is able to deliver around 5400 search
req/s on a laptop, what will be the impact ? How many req/s will we
lose ?

>
> >
> > I also think that the Interceptor I'm working on is not really a log
> > interceptor, as it stores anti-modification, and not the modifications
> > themselves. Should we create another interceptor, or should we store
> > the anti-modification somewhere else?
> >
> > As those anti-modification must be applied in revert order, a file is
> > not really the most appropriate solution.
> >
> > For what we want to use it (reverting to a previous state) we can
> > store the anti-modifications in a stack, in memory.
> >
> > Thoughts ?
>
> Why not store a complete representation of the change as a
> modification and compute the anti-modification only if it is needed?

You can't do that. For a delete operation for instance, you must fetch
the deleted entry before deleting it, because you don't have a copy of
it, and you will lose information. However, it would work for Add and
Modify operations (with a lot of complexity for Modify)

In fact, computing the anti-modification is pretty simple :
- Add =3D=3D> Delete using the DN
- Del =3D=3D> Fetch the old entry and Add it
- Modify =3D=3D> Fetch the previous entry, Delete the modified entry and
Add the fetched entry
- Rename from N1 to N2 =3D=3D> Rename from N2 to N1
- Move from N1 to N2 =3D=3D> Move from N2 to N1

> Then the log can also work as a transaction journal.  I have no idea
> how hard figuring out a complete representation of the change is --
> your other post made it sound like it has a lot of complexity.

The Add and Delete modification are pretty simple. The modify
operation is damn complex. The rename/move operation potentially
impact a hell lot of entries (can be the whole tree), but is simple
too.

>
> thanks
> david jencks
>
> >
> > --
> > Regards,
> > Cordialement,
> > Emmanuel L=E9charny
> > www.iktek.com
>
>


--=20
Regards,
Cordialement,
Emmanuel L=E9charny
www.iktek.com