directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ole Ersoy <ole.er...@gmail.com>
Subject Re: [jira] Closed: (DIRSERVER-950) Server Left in Unstable State
Date Fri, 01 Jun 2007 18:16:28 GMT
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...
> 

Mime
View raw message