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...

Reply via email to