directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emmanuel Lecharny (JIRA)" <>
Subject [jira] [Commented] (DIRSERVER-1974) Rename Operation Issue - ApacheDS
Date Mon, 01 Jul 2019 15:05:00 GMT


Emmanuel Lecharny commented on DIRSERVER-1974:

Here is what might happen :

- The lookup is almost immediate, because it does a search with scope BASE_OBJECT, which fetch
the object in one fetch in the backend.
- The search, OTOH, will proceed through hundred of entries (1000 in this example). The search
engine first creates a set of candidate (the list of {{entryUUID}} for all the entries in
scope ONE_LEVEL), then check every single one of them against the provided filter. Here, the
{{sn}} attribute is not indexed, so we have to go through the 1001 entries (the 1000 original
ones plus the added one). It takes a while.
- If we do a search on all the added entries *before* the loop, then the loop works just fine.

So the thing is that when we run the loop the first time, without having fetched any of the
entries before, it takes longer (the JDBM cache is empty), which may leads to some impact
on the result.

What I don't get is why we get the wrong RDN in the search after the rename during the first
loop. There must be something cached somewhere that blow the result...

Continuing my investigations.

> Rename Operation Issue - ApacheDS
> ---------------------------------
>                 Key: DIRSERVER-1974
>                 URL:
>             Project: Directory ApacheDS
>          Issue Type: Bug
>          Components: jdbm, ldap
>    Affects Versions: 2.0.0-M15
>         Environment: Window server 2008 R2
>            Reporter: Mohd Usman
>            Priority: Blocker
>              Labels: build, features, patch
>         Attachments: ApacheDSSchemaBrowser.png, CNAttributeInSchema.png, PostRename.png,
PreRename.png, SchemaViewerLDAPAdminTool.png
>   Original Estimate: 168h
>  Remaining Estimate: 168h
> Whenever we perform Rename operation on an object entry (let’s say Person object),
the person gets renamed successfully but the issue is that the old value of the person object
still remains.
> The ‘cn’ attribute contains two values now - old value and also the new value.
> Example:
> I have created a person object with DN "cn=person,ou=Apache,dc=example,dc=com" and I
want to rename this entry to "cn=person_Rename,ou=Apache,dc=example,dc=com".
> The rename operation executes successfully and the person is renamed to "cn=person_Rename,ou=Apache,dc=example,dc=com".

> But, the ‘cn’ attribute now contains 
> “person”
> “person_Rename”.
> When verified the schema, ‘cn’ attribute show as ‘single valued’ but after performing
the rename operation – the ‘cn’ becomes ‘multi-valued’ and contains two values.
> This an issue with Apache directory which needs to be resolved. Also find the screenshots
attached for your reference. Please look into the same.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message