Hi All,
I am trying to add a dn to openLDAP using novell's ldap.jar APIs. When I try to add a record it error out with the below exception 1% times :
com.novell.ldap.LDAPException: No Such Object : (32) No Such Object at com.novell.ldap.LDAPResponse.getResultException(LDAPResponse.java:247) at com.novell.ldap.LDAPResponse.chkResultCode(LDAPResponse.java:174) at com.novell.ldap.LDAPConnection.add(LDAPConnection.java:1049) at com.novell.ldap.LDAPConnection.add(LDAPConnection.java:1015) at org.ietf.ldap.LDAPConnection.add(LDAPConnection.java:820)
Could anyone provide any clue to help fix this ?
openLDAP & DB details :
The database which I am trying to update is 24GB in size, OpenLDAP 2.3.27 and BDB backend *4.4.20.* http://4.4.20./ Mac OS Tiger with 4GB RAM. It will be receiving 100 searches / min at an average.
Thanks, Sumith.
Sumith Narayanan wrote:
I am trying to add a dn to openLDAP using novell's ldap.jar APIs. When I try to add a record it error out with the below exception 1% times :
com.novell.ldap.LDAPException: No Such Object : (32) No Such Object
Very likely the entry with the DN under which you want to add the entry does not exist.
Ciao, Michael.
hi , Is your environment a multi threaded one ? Is there a slight possibility that the container might not be added before adding a entry to that ? There is not much I can think of using the information given . If you provide much information than I can look into that .
regards Arpit
"Sumith Narayanan" sumith.narayanan@gmail.com 4/10/2008 4:23 AM >>>
Hi All,
I am trying to add a dn to openLDAP using novell's ldap.jar APIs. When I try to add a record it error out with the below exception 1% times :
com.novell.ldap.LDAPException: No Such Object : (32) No Such Object at com.novell.ldap.LDAPResponse.getResultException(LDAPResponse.java:247) at com.novell.ldap.LDAPResponse.chkResultCode(LDAPResponse.java:174) at com.novell.ldap.LDAPConnection.add(LDAPConnection.java:1049) at com.novell.ldap.LDAPConnection.add(LDAPConnection.java:1015) at org.ietf.ldap.LDAPConnection.add(LDAPConnection.java:820)
Could anyone provide any clue to help fix this ?
openLDAP & DB details :
The database which I am trying to update is 24GB in size, OpenLDAP 2.3.27 and BDB backend 4.4.20. ( http://4.4.20./ ) Mac OS Tiger with 4GB RAM. It will be receiving 100 searches / min at an average.
Thanks, Sumith.
to add a record it error out with the below exception 1% times :
com.novell.ldap.LDAPException: No Such Object : (32) No Such Object
Do you have reason to believe the error is wrong? i.e., does the parent of the entry you are trying to create exist, and do you have appropriate access (even "disclose" comes to mind in this case, let alone write)?
Of course....
The database which I am trying to update is 24GB in size, OpenLDAP 2.3.27
we've definitely had quite a few database fixes since then. Update your server to the latest release as seen on www.openldap.org and try again.
Aaron Richton wrote:
to add a record it error out with the below exception 1% times :
com.novell.ldap.LDAPException: No Such Object : (32) No Such Object
Do you have reason to believe the error is wrong? i.e., does the parent of the entry you are trying to create exist, and do you have appropriate access (even "disclose" comes to mind in this case, let alone write)?
Of course....
The database which I am trying to update is 24GB in size, OpenLDAP 2.3.27
we've definitely had quite a few database fixes since then. Update your server to the latest release as seen on www.openldap.org and try again.
Is it just me or do people on this list never support problems related to anything but the latest release? Not everyone can immediately upgrade to the latest release to fix any issues they have, and they shouldn't have to either. Previous versions (to an extent) should be supported just like any other product.
Is it just me or do people on this list never support problems related to anything but the latest release? Not everyone can immediately upgrade to the latest release to fix any issues they have, and they shouldn't have to either. Previous versions (to an extent) should be supported just like any other product.
Its very difficult for any open source software project to support several year old versions of software that the bugs have been long since fixed. Even if they backported the fixes the user probably could not get them in their distro anyways.
John
John Drescher wrote:
Is it just me or do people on this list never support problems related to anything but the latest release? Not everyone can immediately upgrade to the latest release to fix any issues they have, and they shouldn't have to either. Previous versions (to an extent) should be supported just like any other product.
Its very difficult for any open source software project to support several year old versions of software that the bugs have been long since fixed. Even if they backported the fixes the user probably could not get them in their distro anyways.
Certainly true, but in this case the original poster was already on the current *release* - i.e., 2.3. But they did not have the current *patchlevel*, i.e. there are 14 released patchsets since 2.3.27.
Brandon's question is completely off base. The Project has been actively supporting the 2.3 release for almost 3 years now. For a volunteer effort that's pretty damn good.
Howard Chu wrote:
John Drescher wrote:
Is it just me or do people on this list never support problems related to anything but the latest release? Not everyone can immediately upgrade to the latest release to fix any issues they have, and they shouldn't have to either. Previous versions (to an extent) should be supported just like any other product.
Its very difficult for any open source software project to support several year old versions of software that the bugs have been long since fixed. Even if they backported the fixes the user probably could not get them in their distro anyways.
Certainly true, but in this case the original poster was already on the current *release* - i.e., 2.3. But they did not have the current *patchlevel*, i.e. there are 14 released patchsets since 2.3.27.
Brandon's question is completely off base. The Project has been actively supporting the 2.3 release for almost 3 years now. For a volunteer effort that's pretty damn good.
With that last statement it sounds like you think I'm suggesting you guys don't work hard to fix bugs in old releases which isn't what I originally stated. I meant that it seemed to me like supporting older releases from a *troubleshooting* perspective didn't seem to happen much on this list. Support by backporting patches to old releases and support by troubleshooting old releases without requiring an upgrade prior to troubleshooting are 2 different things. It's akin to companies requiring a supported configuration prior to troubleshooting a problem, even if the supported configuration is technically and seemingly unrelated to the problem. Nothing happens until the supported configuration exists on the customer side. Sometimes it looks like that happens here. Obviously others disagree. Oh well, just my opinion.
Brandon McCombs wrote:
Brandon's question is completely off base. The Project has been actively supporting the 2.3 release for almost 3 years now. For a volunteer effort that's pretty damn good.
With that last statement it sounds like you think I'm suggesting you guys don't work hard to fix bugs in old releases which isn't what I originally stated. I meant that it seemed to me like supporting older releases from a *troubleshooting* perspective didn't seem to happen much on this list. Support by backporting patches to old releases and support by troubleshooting old releases without requiring an upgrade prior to troubleshooting are 2 different things. It's akin to companies requiring a supported configuration prior to troubleshooting a problem, even if the supported configuration is technically and seemingly unrelated to the problem. Nothing happens until the supported configuration exists on the customer side. Sometimes it looks like that happens here. Obviously others disagree. Oh well, just my opinion.
Since troubleshooting is done on a voluntary basis, we do not provide any support for old releases. stop. We provide support for the latest release. stop. So upgrading to the latest is a prerequisite to get (yet voluntary, free and unpaid) support.
Anyone then is free to help others troubleshooting without prior upgrading, but that's another point. In any case, if the troubleshooting without upgrading ends up in discovering and fixing a new bug, the fix will only be released as a patch to the laters release, so an upgrade will be required anyway, unless one is fine with manually patching the old release's source code.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
On Apr 12, 2008, at 2:25 AM, Brandon McCombs wrote:
I meant that it seemed to me like supporting older releases from a *troubleshooting* perspective didn't seem to happen much on this list.
You are welcomed to provide such support. What support others provide is, well, up to them.
-- Kurt
Hi All, thanks for the replies..
there is no problem in adding these dns, as I said it fails only in 1% times, rest 99% times, it goes through fine.
So there is no problem with container or access ....
Is it because of the transaction volumes OR DB size? my server is running below 10% CPU..
Thanks, Sumith.
On Thu, Apr 10, 2008 at 7:24 AM, Brandon McCombs bmccombs@ma.rr.com wrote:
Aaron Richton wrote:
to add a record it error out with the below exception 1% times :
com.novell.ldap.LDAPException: No Such Object : (32) No Such Object
Do you have reason to believe the error is wrong? i.e., does the parent of the entry you are trying to create exist, and do you have appropriate access (even "disclose" comes to mind in this case, let alone write)?
Of course....
The database which I am trying to update is 24GB in size, OpenLDAP
2.3.27
we've definitely had quite a few database fixes since then. Update your server to the latest release as seen on www.openldap.org and try again.
Is it just me or do people on this list never support problems related
to anything but the latest release? Not everyone can immediately upgrade to the latest release to fix any issues they have, and they shouldn't have to either. Previous versions (to an extent) should be supported just like any other product.
Brandon McCombs wrote:
Aaron Richton wrote:
The database which I am trying to update is 24GB in size, OpenLDAP 2.3.27
we've definitely had quite a few database fixes since then. Update your server to the latest release as seen on www.openldap.org and try again.
Is it just me or do people on this list never support problems related to anything but the latest release? Not everyone can immediately upgrade to the latest release to fix any issues they have, and they shouldn't have to either. Previous versions (to an extent) should be supported just like any other product.
It's just you.
The fact that we do point releases is exactly how previous versions get supported. When a bug is found in e.g. 2.3.27 and the fix is released in 2.3.28, then if you want the fix you have to install 2.3.28.
How exactly do you expect people to receive fixes, if not by installing them when they are available?
Howard Chu wrote:
Brandon McCombs wrote:
Aaron Richton wrote:
The database which I am trying to update is 24GB in size, OpenLDAP 2.3.27
we've definitely had quite a few database fixes since then. Update your server to the latest release as seen on www.openldap.org and try again.
Is it just me or do people on this list never support problems related to anything but the latest release? Not everyone can immediately upgrade to the latest release to fix any issues they have, and they shouldn't have to either. Previous versions (to an extent) should be supported just like any other product.
It's just you.
The fact that we do point releases is exactly how previous versions get supported. When a bug is found in e.g. 2.3.27 and the fix is released in 2.3.28, then if you want the fix you have to install 2.3.28.
How exactly do you expect people to receive fixes, if not by installing them when they are available?
There is a difference between knowing definitively whether the OP was running into a bug and by upgrading it would be fixed compared to just telling him he has to upgrade because some bugs have been fixed (not necessarily the one he is running into, if he is even running into one) and that he won't get much or any help unless he does the upgrade. The knee-jerk reaction on this list is usually to tell people to upgrade. That works great if it can have a good chance of fixing the problem but that doesn't usually seem to be the reason people are told to upgrade.
It wasn't specified whether the OP was running into a bug or not. He was just told to upgrade. I'd prefer to know ahead of time if it was me that an upgrade would actually fix it instead of going thru the time of doing it and not fixing it and it having the chance of breaking something else.
It isn't just with this guy's post either. I see "You are way out of date. You need to upgrade." answers to a lot of questions on here. Obviously the best case scenario is for everyone to run the latest code but that isn't always possible
At least some rationale ahead of time for upgrading would be nice in my opinion because I got the impression it is just used as an excuse to not help someone. I'm the type to ask 'why' before I'm told to do something to better evaluate the proposed solution. That may very well be the wrong impression but it is one that was easy to arrive at.
Brandon McCombs wrote:
Howard Chu wrote:
The fact that we do point releases is exactly how previous versions get supported. When a bug is found in e.g. 2.3.27 and the fix is released in 2.3.28, then if you want the fix you have to install 2.3.28.
How exactly do you expect people to receive fixes, if not by installing them when they are available?
There is a difference between knowing definitively whether the OP was running into a bug and by upgrading it would be fixed compared to just telling him he has to upgrade because some bugs have been fixed (not necessarily the one he is running into, if he is even running into one) and that he won't get much or any help unless he does the upgrade. The knee-jerk reaction on this list is usually to tell people to upgrade. That works great if it can have a good chance of fixing the problem but that doesn't usually seem to be the reason people are told to upgrade.
Aaron's response already covered most of the bases http://www.openldap.org/lists/openldap-software/200804/msg00153.html
It wasn't specified whether the OP was running into a bug or not. He was just told to upgrade. I'd prefer to know ahead of time if it was me that an upgrade would actually fix it instead of going thru the time of doing it and not fixing it and it having the chance of breaking something else.
It isn't just with this guy's post either. I see "You are way out of date. You need to upgrade." answers to a lot of questions on here. Obviously the best case scenario is for everyone to run the latest code but that isn't always possible
At least some rationale ahead of time for upgrading would be nice in my opinion because I got the impression it is just used as an excuse to not help someone. I'm the type to ask 'why' before I'm told to do something to better evaluate the proposed solution. That may very well be the wrong impression but it is one that was easy to arrive at.
The OP was already pretty certain that they were not doing anything out of sequence or otherwise wrong. A number of posts were made asking for more details, to ascertain whether some simple misconfiguration may have been at fault. The only thing left is to eliminate any possible bugs. Also, if there's a previously-unknown bug and it isn't fixed in any of the later patches, an upgrade is still required.
The Project's policy on patches is (and has always been, since 1998 when the Project was founded) as noted here:
http://www.openldap.org/devel/contributing.html
patches Each software change should be concise, self-contained, and made against up-to-date source code. <<
Changes are only made against the latest code. Period.
If you think that's a bad policy, (1) you probably have no idea what's really involved here and (2) you're welcome to prove otherwise on your own time. Nobody on the Project has time to retread old ground.
Is it just me or do people on this list never support problems related to anything but the latest release? Not everyone can immediately upgrade to the latest release to fix any issues they have, and they shouldn't have to either. Previous versions (to an extent) should be supported just like any other product.
Well, most "I didn't expect output x" questions end up with:
(0) This behavior is correct; we just need to figure out why/how it came to be. This is upgrade-independent, and I think we're pretty good with prompting users to figure out if it's the case. As an example,
Do you have reason to believe the error is wrong? i.e., does the parent of the entry you are trying to create exist, and do you have appropriate access (even "disclose" comes to mind in this case, let alone write)?
along with the excellent JLDAP code suggestions (it's been years since I've run javac) addressed that in this instance.
(1) This behavior is incorrect; in fact, we've already dealt with it. This obviously requires an upgrade for resolution. Hypothesize that situation--what's going to cause "No such object" as a lie in this situation? Most likely would be some bdb/hdb bug. RE23 CHANGES "egrep bdb|hdb | wc -l" shows 17 fixes since 2.3.27. Wouldn't you want those ALL ruled out?
(2) This behavior is incorrect; we need to work on a solution. This is made a LOT easier when a motivated reporter is on the same page as the developers, which pretty much means running the latest code. The only proper alternative is writing up a clean reproduction, and if a user has that, they'd be posting to the ITS instead of openldap-software. So to this audience, an upgrade is near-required if it hasn't already been undertaken.
Underlying all of this, there's the general Good Citizen maneuver. I mean, 2.3.27 has remote crasher vulnerabilities. Obviously that's something that sites can choose to consciously enter into, but if you're not clearly indicating that you're aware of that situation, we'd be amiss to NOT recommend an upgrade. Plus, if you're correct in the contention that this is improper behavior (#1 or #2), your next maneuver needs to be to upgrade anyway. Bottom line...we're suggesting it because it's the right answer.
Ok.. So which is the latest stable version .. OpenLDAP and BDB ? Thanks, Sumith
On Thu, Apr 10, 2008 at 10:20 AM, Aaron Richton richton@nbcs.rutgers.edu wrote:
Is it just me or do people on this list never support problems related to
anything but the latest release? Not everyone can immediately upgrade to the latest release to fix any issues they have, and they shouldn't have to either. Previous versions (to an extent) should be supported just like any other product.
Well, most "I didn't expect output x" questions end up with:
(0) This behavior is correct; we just need to figure out why/how it came to be. This is upgrade-independent, and I think we're pretty good with prompting users to figure out if it's the case. As an example,
Do you have reason to believe the error is wrong? i.e., does the parent
of the entry you are trying to create exist, and do you have appropriate access (even "disclose" comes to mind in this case, let alone write)?
along with the excellent JLDAP code suggestions (it's been years since I've run javac) addressed that in this instance.
(1) This behavior is incorrect; in fact, we've already dealt with it. This obviously requires an upgrade for resolution. Hypothesize that situation--what's going to cause "No such object" as a lie in this situation? Most likely would be some bdb/hdb bug. RE23 CHANGES "egrep bdb|hdb | wc -l" shows 17 fixes since 2.3.27. Wouldn't you want those ALL ruled out?
(2) This behavior is incorrect; we need to work on a solution. This is made a LOT easier when a motivated reporter is on the same page as the developers, which pretty much means running the latest code. The only proper alternative is writing up a clean reproduction, and if a user has that, they'd be posting to the ITS instead of openldap-software. So to this audience, an upgrade is near-required if it hasn't already been undertaken.
Underlying all of this, there's the general Good Citizen maneuver. I mean, 2.3.27 has remote crasher vulnerabilities. Obviously that's something that sites can choose to consciously enter into, but if you're not clearly indicating that you're aware of that situation, we'd be amiss to NOT recommend an upgrade. Plus, if you're correct in the contention that this is improper behavior (#1 or #2), your next maneuver needs to be to upgrade anyway. Bottom line...we're suggesting it because it's the right answer.
On Thu, 10 Apr 2008, Sumith Narayanan wrote:
Ok.. So which is the latest stable version .. OpenLDAP and BDB ? Thanks, Sumith
The latest RE23 is 2.3.41. Most people find a patched BDB 4.2.52 to be the gold standard, but there are some possibly relevant bugs that are fixed in a patched 4.6.21.
Aaron Richton wrote:
On Thu, 10 Apr 2008, Sumith Narayanan wrote:
Ok.. So which is the latest stable version .. OpenLDAP and BDB ? Thanks, Sumith
The latest RE23 is 2.3.41. Most people find a patched BDB 4.2.52 to be the gold standard, but there are some possibly relevant bugs that are fixed in a patched 4.6.21.
This statement can be misleading for running OpenLDAP 2.3.x since BDB 4.6.x can only be used with OpenLDAP 2.4.x.
Ciao, Michael.
--On Friday, April 11, 2008 9:47 AM +0200 Michael Ströder michael@stroeder.com wrote:
Aaron Richton wrote:
On Thu, 10 Apr 2008, Sumith Narayanan wrote:
Ok.. So which is the latest stable version .. OpenLDAP and BDB ? Thanks, Sumith
The latest RE23 is 2.3.41. Most people find a patched BDB 4.2.52 to be the gold standard, but there are some possibly relevant bugs that are fixed in a patched 4.6.21.
This statement can be misleading for running OpenLDAP 2.3.x since BDB 4.6.x can only be used with OpenLDAP 2.4.x.
I think the point was, there has been a recent patch to BDB 4.6.21, and the issue that patch fixes looks like it is present in all 4.2->4.5 releases. On the other hand, I don't believe anyone has hit the issue it fixes in the years folks have been running 4.2+. So maybe OpenLDAP doesn't exercise the problematic code path. Or perhaps something about 4.6 itself made it more likely to trigger.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
openldap-software@openldap.org
-
Aaron Richton -
Brandon McCombs -
Howard Chu -
John Drescher -
Kurt Zeilenga -
Michael Ströder -
Pierangelo Masarati -
Quanah Gibson-Mount -
Rastogi Arpit -
Sumith Narayanan