You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by "Emmanuel Lecharny (JIRA)" <ji...@apache.org> on 2007/06/01 20:10:15 UTC
[jira] Closed: (DIRSERVER-950) Server Left in Unstable State
[ https://issues.apache.org/jira/browse/DIRSERVER-950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Emmanuel Lecharny closed DIRSERVER-950.
---------------------------------------
Resolution: Invalid
So far, unless you fond a clear and reproductible test case for this problem, as you found the cause and as it seems that it's a problem in your coee, I close this issue.
> Server Left in Unstable State
> -----------------------------
>
> Key: DIRSERVER-950
> URL: https://issues.apache.org/jira/browse/DIRSERVER-950
> Project: Directory ApacheDS
> Issue Type: Bug
> Affects Versions: 1.5.0
> Environment: FC6
> Reporter: Ole Ersoy
> Priority: Minor
>
> I can only give observational data
> for this, since it appears to be a one time thing.
> It's a little like the sequence of what happened depends
> on threads, and thread A completes first 9999/10000 times,
> but in this case thread B completed first...
> I ran the test:
> EObjectClassCreator
> It creates an ObjectClass and the
> AttributeTypes needed by the ObjectClass.
> I've ran it several times successfully already,
> but on the last run it left the server in
> a state that does not let me delete
> an entry shown in LS.
> I have a single entry (That should have been cleaned by the test)
> ou=objectClasses, cn=ecore, ou=schema
> This has no children.
> If I refresh in LS it is still there.
> I check to make sure the apacheds daemon is still running.
> If I try to delete I get this:
> Error while deleting entry
> [LDAP: error code 80 - failed on search operation: OID for name 'metatopsdo' was not found within the OID registry]
> [LDAP: error code 80 - failed on search operation: OID for name 'metatopsdo' was not found within the OID registry]
> metatopsdo is an objectClass that was created in order to create
> the ObjectClass entry that the test creates.
> Once the test has run the ObjectClass entry
> created is deleted,
> then the metatopsdo ObjectClass.
> This is strange because the entry
> ou=objectClasses, cn=ecore, ou=schema
> is empty, at least as shown is LS.
> So the question is under what circumstances does
> is LS not able to delete an empty entry like this.
> I'm now going to disconnect and reconnect
> with LS to see if it has an effect.
> OK - I did that and
> when drill down past the entry
> ou=objectClasses, cn=ecore, ou=schema
> I get this:
> Error while reading entry
> [LDAP: error code 80 - failed on search operation: OID for name 'metatopsdo' was not found within the OID registry]
> [LDAP: error code 80 - failed on search operation: OID for name 'metatopsdo' was not found within the OID registry]
> So the ObjectClass entry the test created
> must be there, but LS can't see it because
> the metatopsdo ObjectClass is deleted,
> at least it seems.
> But ApacheDS should disallow deletion
> of metatopsdo when it is being used by another
> ObjectClass entry right?
> I think the only thing I can do now is to
> reinstall the server...since the entry
> is "Stuck"...
> But first let me try restarting it
> just in case...
> yum still stuck.
> Just in case the teardown for this test looks like this:
> EObjectClassDestroyer.
> destroy(
> ecoreAttributeTypesContext,
> ecoreObjectClassesContext,
> eClass,
> oidPrefix );
> MetaTopSDOObjectClassDestroyer.
> destroy(
> ecoreAttributeTypesContext,
> ecoreObjectClassesContext,
> oidPrefix );
>
> EcoreTypeSystemDestroyer.
> destroy(
> ecoreSyntaxesContext,
> oidPrefix);
>
> super.tearDown();
> So it's really strange that it got stuck like this...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Closed: (DIRSERVER-950) Server Left in Unstable State
Posted by Ole Ersoy <ol...@gmail.com>.
> I run it at the TLP. I have learnt the hard way to always run maven at
> the TLP...
OK - Cool - Thanks for giving it a shot. I'll start coding the self contained asap. Should have it done in a few days. Just want to make sure I get all the DAS coding done while the ideas are fresh, avoiding the "What is this DAS thing and why is it in my project area?" scenario.
Cheers,
- Ole
Re: [jira] Closed: (DIRSERVER-950) Server Left in Unstable State
Posted by Emmanuel Lecharny <el...@apache.org>.
Ole Ersoy a écrit :
>
> Emmanuel Lecharny wrote:
>
>>> Did you try:
>>> mvn eclipse:clean elipse:eclipse
>>
>>
>> Yes, but it does not import the missing jars.
>
>
> Dab Gum. They are in a public repository, but the mvn eclipse:clean
> eclipse:eclipse would have to be run at the parent level
> (das.ldap.parent) because I'm using maven dependency management.
I run it at the TLP. I have learnt the hard way to always run maven at
the TLP...
Emmanuel
Re: [jira] Closed: (DIRSERVER-950) Server Left in Unstable State
Posted by Ole Ersoy <ol...@gmail.com>.
Emmanuel Lecharny wrote:
>> Did you try:
>> mvn eclipse:clean elipse:eclipse
>
> Yes, but it does not import the missing jars.
Dab Gum. They are in a public repository, but the mvn eclipse:clean eclipse:eclipse would have to be run at the parent level (das.ldap.parent) because I'm using maven dependency management. Did you try running it at the parent level? If that is caputo as well, I'll code a self contained test ASAP. Hang in there :-).
Thanks,
- Ole
Re: [jira] Closed: (DIRSERVER-950) Server Left in Unstable State
Posted by Emmanuel Lecharny <el...@apache.org>.
Ole Ersoy a écrit :
>> Ok, I tried, and it failed.
>
>
> Yes - This is great. It's supposed to fail. Now the server will be
> in the state described.
Sorry, I meant, "I tried to download the test and to run it, but I
failed to run it".
>> This is why the URL you gave is not a good idea... There is no way I
>> can run the test without a massive cleanup ...
>
>
> Did you try:
> mvn eclipse:clean elipse:eclipse
Yes, but it does not import the missing jars.
Emmanuel
Re: [jira] Closed: (DIRSERVER-950) Server Left in Unstable State
Posted by Ole Ersoy <ol...@gmail.com>.
> Ok, I tried, and it failed.
Yes - This is great. It's supposed to fail. Now the server will be in the state described.
Did you look in LS and try to delete/refresh the entry I described?
I'm still working on my svn skills. I have an svn server setup and I'm going to start running little tests to make sure I check in clean/minimal project files.
This was just a quicky one time thing to make sure I captured the "Server Breakage" scenario.
> This is why the URL you gave is not a good idea... There is no way I can
> run the test without a massive cleanup ...
Did you try:
mvn eclipse:clean elipse:eclipse
This should clean all the eclipse files and then regenerate them for your system.
> Sorry, it's in example.com. You have three sub-dirs, example, system and
> schema. Simply remove the example.com directoy, the system and schema
> directories will be recreated when the server will be restarted.
Awesome - I'm definitely putting that one in the "Little black book".
Thanks,
- Ole
Emmanuel Lecharny wrote:
>
>>
>> =======================================================================
>> 3) You pointed us to a test which is somewhere on the web. Don't do
>> that, it's not convenient, because your test will be very contextual.
>> Just attach the whole working test.
>> =======================================================================
>>
>> Sure - I like quick self contained tests. In this case "The Whole
>> Working Test" is a fairly massive test setup, along with the test.
>> Therefore there is an option I would like us to consider because I
>> would have to invest a significant amount of time in translating the
>> "Massive test setup" into a single self contained test, in addition to
>> the 2-3 hours I spent documenting and isolating this thing. We could
>> do this:
>> svn co
>> https://svn.apache.org/repos/asf/directory/sandbox/oersoy/das.testing/das.ldap.parent
>> das.ldap.parent
>
> Ok, I tried, and it failed. This is one of the reason it's better to
> attach a standalone test. Anyway, here are some comments about the test :
> - you have injected .classpath and .project into SVN, and this is not a
> good idea, as it may not be used directly on another version of eclipse.
> I'ts better to use mvn eclipse:eclipse which will generate those files.
> Moreover, those .classpath points to resources that are not loaded on my
> computer (old versions of apacheds and shared), mvn would have
> downloaded them.
> - you are refering to incompatible versions of apacheds (namely, 1.0.).
> This is not good
> - you are also refering to a lot of eclipse plugin I don't have on my
> eclipse installation (emf and xsd, using old versions of them).
>
> This is why the URL you gave is not a good idea... There is no way I can
> run the test without a massive cleanup ...
>
>>
>> Import the child projects into eclipse. Run the test described. View
>> the context ou=objectClasses, cn=ecore, ou=schema in LS. Verify my
>> observation, being mainly that this context is now "Broken".
>>
>> This should take about 2 minutes. If for some reason my observation
>> is missing come back to me and ask me to code a self contained test.
>
> I think that what I explained in my previous point forbid me to run the
> test without some more work, and it won't be 2 minutes for me to fix it
> ... I'm sorry about that !
>
>> I'll be happy to do it. Is this a fair request?
>
> I's plain fair.
>
>> Ideally I think myself and the person fixing this would work together,
>> and come up with an integrated test suite targeted at keeping these
>> types of fixes fixed. If I code another test it could be that the
>> person I throw it over the wall to ends up recoding it anyways. I'll
>> be glad to help in any way I can, I just want us to be smart in terms
>> of how we work together.
>
> The main problem is that when it comes to complex problems, you have to
> factor of complexity :
> - the potential bug in the server. If the bug does not occurs in very
> specific circonstances, then writing a focused test is complex.
> - the complexity of your code : it's always painfull to select the part
> of it which demonstrates the error
>
> Now, I would say that this is fair to ask the user to make the effort
> first. The reason is that 99% of the cases, the error is hidden somwhere
> in the user code. How many times did you heard about "damn <select you
> favorite product/API>, it's fully buggy", and after a little
> investigation, you discover that the error is in the client code ? We
> see it all the times (just check MINA bug reports, it's always the same
> thing :
> "Q: there is a bug in MINA, blah blah blah..."
> "A: Are you sure? Can you check that and that?"
> "Q: Oh, well, that fixed the bug, I mean, it's working now ..."
>
> We have bugs in the server, that's obvious. But if we have to spend some
> time to check for every supposed bug, before discarding them, we won't
> be able to fix any real bugs ... This is very true for complex tests.
>
> This is the reason we ask users to do their homeworks before bringing
> the problem to us, not because we are lazzy, but because of the lack of
> time...
>
>>
>> =======================================================================
>> Last thing : you don't have to reinstall the server : just delete the
>> data (a directory called example.com, or whatever name you gave to
>> your partition, plus the schema directory in server-work). It will do
>> the trick.
>> =======================================================================
>>
>> Oh OK - I looked under apacheds-1.5.0/var...and did not see a
>> server-work... Also all the entries created by the test are under
>> ou=schema. Does this still apply? I'm guessing if I delete the
>> entire schema partition, the server will just recreate it when it
>> restarts?
>
> Sorry, it's in example.com. You have three sub-dirs, example, system and
> schema. Simply remove the example.com directoy, the system and schema
> directories will be recreated when the server will be restarted.
>
> Emmanuel
>
>
Re: [jira] Closed: (DIRSERVER-950) Server Left in Unstable State
Posted by Emmanuel Lecharny <el...@apache.org>.
Ole Ersoy a écrit :
> Thanks for all the comments. I read them carefully a few times I did
> and I agree with everything you said. I'll take notes in a separate
> memo pad, and then come up with a quick concise summary for JIRA.
Thanks Ole. Doing so will help a lot !
>
> =======================================================================
> 3) You pointed us to a test which is somewhere on the web. Don't do
> that, it's not convenient, because your test will be very contextual.
> Just attach the whole working test.
> =======================================================================
>
> Sure - I like quick self contained tests. In this case "The Whole
> Working Test" is a fairly massive test setup, along with the test.
> Therefore there is an option I would like us to consider because I
> would have to invest a significant amount of time in translating the
> "Massive test setup" into a single self contained test, in addition to
> the 2-3 hours I spent documenting and isolating this thing.
> We could do this:
> svn co
> https://svn.apache.org/repos/asf/directory/sandbox/oersoy/das.testing/das.ldap.parent
> das.ldap.parent
Ok, I tried, and it failed. This is one of the reason it's better to
attach a standalone test. Anyway, here are some comments about the test :
- you have injected .classpath and .project into SVN, and this is not a
good idea, as it may not be used directly on another version of eclipse.
I'ts better to use mvn eclipse:eclipse which will generate those files.
Moreover, those .classpath points to resources that are not loaded on my
computer (old versions of apacheds and shared), mvn would have
downloaded them.
- you are refering to incompatible versions of apacheds (namely, 1.0.).
This is not good
- you are also refering to a lot of eclipse plugin I don't have on my
eclipse installation (emf and xsd, using old versions of them).
This is why the URL you gave is not a good idea... There is no way I can
run the test without a massive cleanup ...
>
> Import the child projects into eclipse. Run the test described. View
> the context ou=objectClasses, cn=ecore, ou=schema in LS. Verify my
> observation, being mainly that this context is now "Broken".
>
> This should take about 2 minutes. If for some reason my observation
> is missing come back to me and ask me to code a self contained test.
I think that what I explained in my previous point forbid me to run the
test without some more work, and it won't be 2 minutes for me to fix it
... I'm sorry about that !
> I'll be happy to do it. Is this a fair request?
I's plain fair.
> Ideally I think myself and the person fixing this would work together,
> and come up with an integrated test suite targeted at keeping these
> types of fixes fixed. If I code another test it could be that the
> person I throw it over the wall to ends up recoding it anyways. I'll
> be glad to help in any way I can, I just want us to be smart in terms
> of how we work together.
The main problem is that when it comes to complex problems, you have to
factor of complexity :
- the potential bug in the server. If the bug does not occurs in very
specific circonstances, then writing a focused test is complex.
- the complexity of your code : it's always painfull to select the part
of it which demonstrates the error
Now, I would say that this is fair to ask the user to make the effort
first. The reason is that 99% of the cases, the error is hidden somwhere
in the user code. How many times did you heard about "damn <select you
favorite product/API>, it's fully buggy", and after a little
investigation, you discover that the error is in the client code ? We
see it all the times (just check MINA bug reports, it's always the same
thing :
"Q: there is a bug in MINA, blah blah blah..."
"A: Are you sure? Can you check that and that?"
"Q: Oh, well, that fixed the bug, I mean, it's working now ..."
We have bugs in the server, that's obvious. But if we have to spend some
time to check for every supposed bug, before discarding them, we won't
be able to fix any real bugs ... This is very true for complex tests.
This is the reason we ask users to do their homeworks before bringing
the problem to us, not because we are lazzy, but because of the lack of
time...
>
> =======================================================================
> Last thing : you don't have to reinstall the server : just delete the
> data (a directory called example.com, or whatever name you gave to
> your partition, plus the schema directory in server-work). It will do
> the trick.
> =======================================================================
>
> Oh OK - I looked under apacheds-1.5.0/var...and did not see a
> server-work... Also all the entries created by the test are under
> ou=schema. Does this still apply? I'm guessing if I delete the
> entire schema partition, the server will just recreate it when it
> restarts?
Sorry, it's in example.com. You have three sub-dirs, example, system and
schema. Simply remove the example.com directoy, the system and schema
directories will be recreated when the server will be restarted.
Emmanuel
Re: [jira] Closed: (DIRSERVER-950) Server Left in Unstable State
Posted by Ole Ersoy <ol...@gmail.com>.
Emmanuel,
Thanks for all the comments. I read them carefully a few times I did and I agree with everything you said. I'll take notes in a separate memo pad, and then come up with a quick concise summary for JIRA.
=======================================================================
3) You pointed us to a test which is somewhere on the web. Don't do that, it's not convenient, because your test will be very contextual. Just attach the whole working test.
=======================================================================
Sure - I like quick self contained tests. In this case "The Whole Working Test" is a fairly massive test setup, along with the test. Therefore there is an option I would like us to consider because I would have to invest a significant amount of time in translating the "Massive test setup" into a single self contained test, in addition to the 2-3 hours I spent documenting and isolating this thing.
We could do this:
svn co https://svn.apache.org/repos/asf/directory/sandbox/oersoy/das.testing/das.ldap.parent das.ldap.parent
Import the child projects into eclipse. Run the test described. View the context ou=objectClasses, cn=ecore, ou=schema in LS. Verify my observation, being mainly that this context is now "Broken".
This should take about 2 minutes. If for some reason my observation is missing come back to me and ask me to code a self contained test. I'll be happy to do it. Is this a fair request? Ideally I think myself and the person fixing this would work together, and come up with an integrated test suite targeted at keeping these types of fixes fixed. If I code another test it could be that the person I throw it over the wall to ends up recoding it anyways. I'll be glad to help in any way I can, I just want us to be smart in terms of how we work together.
=======================================================================
Last thing : you don't have to reinstall the server : just delete the
data (a directory called example.com, or whatever name you gave to your
partition, plus the schema directory in server-work). It will do the trick.
=======================================================================
Oh OK - I looked under apacheds-1.5.0/var...and did not see a server-work... Also all the entries created by the test are under ou=schema. Does this still apply? I'm guessing if I delete the entire schema partition, the server will just recreate it when it restarts?
Thanks,
- Ole
Emmanuel Lecharny wrote:
> Ole,
>
> i'm pleased you understand that there were a pb with the JIRA, but I
> also have to tell you, after having read it again, that the pb seems to
> be tricky, so I understand you had to track it step by step.
>
> However, it would be good if you try to follow a better heuristic when
> tracking a bug, and filing a JIRA. Here are some comments on each of
> your additions in the initial JIRA :
>
> 1) The first comment was fine, except that it was pretty long, and did
> not help to understand what is happening, except that the server has a
> problem. If you find something which is not expected, and you feel like
> it might be a bug, then first try to find the *shortest* possible
> description, or write a test which expose the problem clearly. A few
> lines of code are better than 200 lines of comments (remember that we
> all speak 'java', but that we are mainly not english speakers)
>
> 2) The second comment is totally out of scope. It should not have been
> added. The exception was clear enough abouyt what happened
>
> 3) You pointed us to a test which is somewhere on the web. Don't do
> that, it's not convenient, because your test will be very contextual.
> Just attach the whole working test.
>
> 4) You say that you can reproduce the bug. Fine. Then just attach the
> new test, with a single explanation. Again, a few lines of JAVA are
> better than 10 lines of comments. However, the second paragraph is
> needed, because it carries interesting informations
>
> 5) The best comment you added, when I read it for the third time,
> because now I can understand what happens. But be factual, and try to
> give the simplest possible explaination for the poor committer who will
> try to understand the problem.
>
> I would add that JIRA is not a Memo pad, so if you can spend some more
> time to analyze the problem, then you will add less comments and
> probably more accurates.
>
> Remember one thing : if the bug report is fuzzy, then the fix will be
> fuzzy too. Of course, sometime, this is not easy to know what is the
> cause, but if it's difficult for you, it'as also difficult for us. You
> have an advantage, you are just trying to make the test working, so you
> are very focused on the problem, when we are just doing something
> probably not related. If you want us to be able to dive into the problem
> fast enough, you have to keep it very clear.
>
> Last thing : you don't have to reinstall the server : just delete the
> data (a directory called example.com, or whatever name you gave to your
> partition, plus the schema directory in server-work). It will do the trick.
>
> Emmanuel
>
>
Re: [jira] Closed: (DIRSERVER-950) Server Left in Unstable State
Posted by Emmanuel Lecharny <el...@apache.org>.
Ole,
i'm pleased you understand that there were a pb with the JIRA, but I
also have to tell you, after having read it again, that the pb seems to
be tricky, so I understand you had to track it step by step.
However, it would be good if you try to follow a better heuristic when
tracking a bug, and filing a JIRA. Here are some comments on each of
your additions in the initial JIRA :
1) The first comment was fine, except that it was pretty long, and did
not help to understand what is happening, except that the server has a
problem. If you find something which is not expected, and you feel like
it might be a bug, then first try to find the *shortest* possible
description, or write a test which expose the problem clearly. A few
lines of code are better than 200 lines of comments (remember that we
all speak 'java', but that we are mainly not english speakers)
2) The second comment is totally out of scope. It should not have been
added. The exception was clear enough abouyt what happened
3) You pointed us to a test which is somewhere on the web. Don't do
that, it's not convenient, because your test will be very contextual.
Just attach the whole working test.
4) You say that you can reproduce the bug. Fine. Then just attach the
new test, with a single explanation. Again, a few lines of JAVA are
better than 10 lines of comments. However, the second paragraph is
needed, because it carries interesting informations
5) The best comment you added, when I read it for the third time,
because now I can understand what happens. But be factual, and try to
give the simplest possible explaination for the poor committer who will
try to understand the problem.
I would add that JIRA is not a Memo pad, so if you can spend some more
time to analyze the problem, then you will add less comments and
probably more accurates.
Remember one thing : if the bug report is fuzzy, then the fix will be
fuzzy too. Of course, sometime, this is not easy to know what is the
cause, but if it's difficult for you, it'as also difficult for us. You
have an advantage, you are just trying to make the test working, so you
are very focused on the problem, when we are just doing something
probably not related. If you want us to be able to dive into the problem
fast enough, you have to keep it very clear.
Last thing : you don't have to reinstall the server : just delete the
data (a directory called example.com, or whatever name you gave to your
partition, plus the schema directory in server-work). It will do the trick.
Emmanuel
Re: [jira] Closed: (DIRSERVER-950) Server Left in Unstable State
Posted by Ole Ersoy <ol...@gmail.com>.
Emmanuel Lecharny wrote:
> Ole Ersoy a écrit :
>
>> Well,
>>
>> If you consider the server being left in an unrecoverable state due to
>> basic JNDI operations then that's a good move.
>>
>> - Ole
>
> Didn't you found that the cause was that there were some broken logic in
> the test ? Here is your last comment :
Yes - I should have probably put a "Caution" around that statement. There was broken logic in the code the test was running that caused ObjectClass A not to be deleted before ObjectClass B. This then leads to the server being left in a state where JNDI operations on the context containing ObjectClass A and ObjectClass B will fail. For instance children of the context cannot be listed, etc. So the only way to recover is to reinstall the server.
>
> "When the test runs it is supposed to delete ObjectClass A first, but
> the logic was broken"
>
> If you have a clear test case to demonstrate a problem in the server,
> and not in your test, then repoen the issue, and attach the test case.
The test is referenced in this comment:
https://issues.apache.org/jira/browse/DIRSERVER-950#action_12500469
Sorry there were so many comments. Especially the first one :-). In the beginning I thought this might be a tricky thing to track down, so that wanted to make sure I captured as much information as possible. I think if the server simply throws an exception when an attempt to delete a schema entry that has other schema entries dependent on it is made, it will solve the problem.
>
> I may miss something, but consider that the initial JIRA and the added
> comments didn't help at all to understand where the problem is.
Sure - Sorry - I should have documented more clearly in the end. Initially I just noticed that I had to reinstall the server in order to recover, so I wanted to capture all the symptoms around the process, before I attempted to isolate. I'm changing things on my system so fast that occasionally recovering the original state is very tricky. This way at least there was something. I'll try to do it more cleanly though.
Thanks,
- Ole
Re: [jira] Closed: (DIRSERVER-950) Server Left in Unstable State
Posted by Emmanuel Lecharny <el...@apache.org>.
Ole Ersoy a écrit :
> Well,
>
> If you consider the server being left in an unrecoverable state due to
> basic JNDI operations then that's a good move.
>
> - Ole
Didn't you found that the cause was that there were some broken logic in
the test ? Here is your last comment :
"When the test runs it is supposed to delete ObjectClass A first, but
the logic was broken"
If you have a clear test case to demonstrate a problem in the server,
and not in your test, then repoen the issue, and attach the test case.
I may miss something, but consider that the initial JIRA and the added
comments didn't help at all to understand where the problem is.
Emmanuel
Re: [jira] Closed: (DIRSERVER-950) Server Left in Unstable State
Posted by Ole Ersoy <ol...@gmail.com>.
Well,
If you consider the server being left in an unrecoverable state due to basic JNDI operations then that's a good move.
- Ole
Emmanuel Lecharny (JIRA) wrote:
> [ https://issues.apache.org/jira/browse/DIRSERVER-950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
>
> Emmanuel Lecharny closed DIRSERVER-950.
> ---------------------------------------
>
> Resolution: Invalid
>
> So far, unless you fond a clear and reproductible test case for this problem, as you found the cause and as it seems that it's a problem in your coee, I close this issue.
>
>> Server Left in Unstable State
>> -----------------------------
>>
>> Key: DIRSERVER-950
>> URL: https://issues.apache.org/jira/browse/DIRSERVER-950
>> Project: Directory ApacheDS
>> Issue Type: Bug
>> Affects Versions: 1.5.0
>> Environment: FC6
>> Reporter: Ole Ersoy
>> Priority: Minor
>>
>> I can only give observational data
>> for this, since it appears to be a one time thing.
>> It's a little like the sequence of what happened depends
>> on threads, and thread A completes first 9999/10000 times,
>> but in this case thread B completed first...
>> I ran the test:
>> EObjectClassCreator
>> It creates an ObjectClass and the
>> AttributeTypes needed by the ObjectClass.
>> I've ran it several times successfully already,
>> but on the last run it left the server in
>> a state that does not let me delete
>> an entry shown in LS.
>> I have a single entry (That should have been cleaned by the test)
>> ou=objectClasses, cn=ecore, ou=schema
>> This has no children.
>> If I refresh in LS it is still there.
>> I check to make sure the apacheds daemon is still running.
>> If I try to delete I get this:
>> Error while deleting entry
>> [LDAP: error code 80 - failed on search operation: OID for name 'metatopsdo' was not found within the OID registry]
>> [LDAP: error code 80 - failed on search operation: OID for name 'metatopsdo' was not found within the OID registry]
>> metatopsdo is an objectClass that was created in order to create
>> the ObjectClass entry that the test creates.
>> Once the test has run the ObjectClass entry
>> created is deleted,
>> then the metatopsdo ObjectClass.
>> This is strange because the entry
>> ou=objectClasses, cn=ecore, ou=schema
>> is empty, at least as shown is LS.
>> So the question is under what circumstances does
>> is LS not able to delete an empty entry like this.
>> I'm now going to disconnect and reconnect
>> with LS to see if it has an effect.
>> OK - I did that and
>> when drill down past the entry
>> ou=objectClasses, cn=ecore, ou=schema
>> I get this:
>> Error while reading entry
>> [LDAP: error code 80 - failed on search operation: OID for name 'metatopsdo' was not found within the OID registry]
>> [LDAP: error code 80 - failed on search operation: OID for name 'metatopsdo' was not found within the OID registry]
>> So the ObjectClass entry the test created
>> must be there, but LS can't see it because
>> the metatopsdo ObjectClass is deleted,
>> at least it seems.
>> But ApacheDS should disallow deletion
>> of metatopsdo when it is being used by another
>> ObjectClass entry right?
>> I think the only thing I can do now is to
>> reinstall the server...since the entry
>> is "Stuck"...
>> But first let me try restarting it
>> just in case...
>> yum still stuck.
>> Just in case the teardown for this test looks like this:
>> EObjectClassDestroyer.
>> destroy(
>> ecoreAttributeTypesContext,
>> ecoreObjectClassesContext,
>> eClass,
>> oidPrefix );
>> MetaTopSDOObjectClassDestroyer.
>> destroy(
>> ecoreAttributeTypesContext,
>> ecoreObjectClassesContext,
>> oidPrefix );
>>
>> EcoreTypeSystemDestroyer.
>> destroy(
>> ecoreSyntaxesContext,
>> oidPrefix);
>>
>> super.tearDown();
>> So it's really strange that it got stuck like this...
>