Adding another value to an attribute results in the value to be added twice

• Key: DIRSERVER-783
• Type: Bug
• Status: Closed
• Resolution: Fixed
• Priority: Blocker
• Assignee: Emmanuel Lecharny
• Reporter: Ate Douma
• Affects Version/s: 1.0
• Fix Version/s: 1.0.1

Description

If I add a new attribute to a class, its value is stored fine.
But, if I thereafter add another value for the same attribute, this value is added twice.
I encountered this with Jetspeed-2 ldap unit tests, but could then easily reproduce this with for instance LDAP Browser\Editor v.2.8.2

Comments

[Stefan Zoerner]

I am not able to reproduce this error. We need more information.
Please check the attached test case. It creates an entry with a description and adds two other description values. Afterwards the entry looks like it should:

$ ldapsearch -D "uid=admin,ou=system" -w ***** -p 10389 -s one -b "dc=example,dc=com" "(cn=Fiona Apple)"
dn: cn=Fiona Apple,dc=example,dc=com
description: an American singer-songwriter
description: Grammy award winning
description: MTV Music Award winning
objectclass: person
objectclass: top
sn: Apple
cn: Fiona Apple

What is the difference in your situation?

[Ate Douma]

Thanks for following up Stefan.

At first, I couldn't reproduce the problem with your testcase until I made a small modification.
In your testcase your create the entry with the description attribute and then add 2 more values.
But, if you first create the entry *without* the description attribute and thereafter add the three values for the description attribute, the problem surfaces:

junit.framework.AssertionFailedError: expected:<3> but was:<5>
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.failNotEquals(Assert.java:282)
at junit.framework.Assert.assertEquals(Assert.java:64)
at junit.framework.Assert.assertEquals(Assert.java:201)
at junit.framework.Assert.assertEquals(Assert.java:207)
at add.AddingAnotherValueToAnAttribute.testAddAnotherValueToAnAttribute(AddingAnotherValueToAnAttribute.java:100)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:128)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

I've attached the modified testcase as well as the apacheds-stdout.log which clearly shows what happened.
I also noticed the apacheds-stderr.log contains two error messages: "jsvc.exec error: syscall failed in set_caps"
Maybe that's related to this issue?

Finally, for completeness, this is the ldif export after the testcase:

dn: dc=example,dc=com
dc: example
objectclass: top
objectclass: domain
objectclass: extensibleObject

dn: cn=Fiona Apple, dc=example,dc=com
objectclass: person
objectclass: top
description: an American singer-songwriter
description: Grammy award winning
description: Grammy award winning
description: MTV Music Award winning
description: MTV Music Award winning
sn: Apple
cn: Fiona Apple

Hopefully you will be able to reproduce this problem now too.

[Stefan Zoerner]

Yes, I can confirm the problem. It is definitely an error within our software.
Thanks for the modified test case and the detailed information. Stefan

Should be fixed within the next release of the 1.0 branch.

[Alex Karasulu]

Increasing severity. I'd say this is a pretty critical bug that needs to be zapped right away in a 1.0.1.

[Emmanuel Lecharny]

Ok, the problem has been insolated. When we ask for a modification of an entry, we do the following operations :
1) in SchemaService, we clone the entry
2) then we apply the modification on the clone, to check that the modification is acceptable
3) we go down the interceptor chain to EventService where we get again the original entry (the clone has been ditched)
4) in JdbmBackend, we finally apply the modification.

But at thsi point, the clone is still alive, and as stated by Java doco of Basic Attribute.clone() :
"Makes a copy of the attribute. The copy contains the same attribute values as the original attribute: the attribute values are not themselves cloned"

So we are in a bad position here ...

We gonna find a workaround.

[Emmanuel Lecharny]

Raised to blocker, this is really one of the biggest issues we ever had

[Emmanuel Lecharny]

Fixed in 1.0-trunks. The patch will be ported to 1.5 in the next few days.

committed in 1.0-trunks : http://svn.apache.org/viewvc?view=rev&rev=493916

[Emmanuel Lecharny]

Finished to patch trunks :
http://svn.apache.org/viewvc?view=rev&rev=494161 to http://svn.apache.org/viewvc?view=rev&rev=494171
and
http://svn.apache.org/viewvc?view=rev&rev=494173 to http://svn.apache.org/viewvc?view=rev&rev=494177