directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ole Ersoy (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DIRSERVER-950) Server Left in Unstable State
Date Thu, 31 May 2007 20:02:16 GMT

    [ https://issues.apache.org/jira/browse/DIRSERVER-950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12500469
] 

Ole Ersoy commented on DIRSERVER-950:
-------------------------------------

Good news.  We can reproduce.
I'm going to check the whole DAS in,
because the tests are somewhat ingrained.
The test that produces the result
is in the project das.ldap.parent/das.ldap.
It's name is EObjectClassCreatorTest.
The test will fail, and after the 
failure the server will be in the state described.

This is the URL to the DAS parent project:
https://svn.apache.org/repos/asf/directory/sandbox/oersoy/das.testing/das.ldap.parent
The test is in the package:
org.apache.tuscany.das.ldap.schema.emf.create.test



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


Mime
View raw message