|
Home > Archive > Apache Directory Project > December 2007 > Possible defect in 1.5.1: error code 54 - failed on search operation
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Possible defect in 1.5.1: error code 54 - failed on search operation
|
|
| Simon.Temple-bNHniqfy2KDk7dXyY5I9mNBPR1lH4CV8@ 2007-12-19, 1:11 pm |
| Using LDAP Studio 0.8.0 I create a new child entry beneath: uid=admin,ou=system. I then restart DS. Following the restart, if I try to expand the node uid=admin,ou=system to show the child entry I created I get an error:
LDAP: error code 54 - failed on search operation: Unexpected exception.
I do not get this error prior to the restart. There are no errors in theserver side log. (log4j.rootCategory=WARN)
** This only appears to be problem when I create the child entry using anobjectClass I have defined in a custom schema which I load via an LDIF.
i.e. It's not a problem if I stick to entries made up of objectClasses that are part of the 'Bootstrap Schema'
To re-create this, simply used the LDIF I have embedded in this mail and create a child entry of class: ssoApplicationAssociation beneath uid=admin,ou=system (The LDIF was creating using LDAP Studio from the attached 'OpenLDAP Style' Schema.)
Is this a defect, has a JIRA entry already been created for this?
Many Thanks
Simon Temple
(Using: apacheds-server-1.5.1-setup.exe on Windows 2003 Server using jdk1.5.0_11)
---------------------------------- test.ldif ----------------------------------
# test
# Generated by LDAP Studio on 19 December 2007 12:41:08
dn: cn=test, ou=schema
objectclass: metaSchema
objectclass: top
cn: test
m-dependencies: system
dn: ou=attributeTypes, cn=test, ou=schema
objectclass: organizationalUnit
objectclass: top
ou: attributetypes
dn: m-oid=1.2.826.0.1.2221664.8.1.8, ou=attributeTypes, cn=test, ou=schema
objectclass: metaAttributeType
objectclass: metaTop
objectclass: top
m-oid: 1.2.826.0.1.2221664.8.1.8
m-name: aid
m-name: applicationId
m-description: Application identifier
m-equality: caseIgnoreMatch
m-substr: caseIgnoreSubstringsMatch
m-syntax: 1.3.6.1.4.1.1466.115.121.1.15
dn: ou=comparators, cn=test, ou=schema
objectclass: organizationalUnit
objectclass: top
ou: comparators
dn: ou=ditContentRules, cn=test, ou=schema
objectclass: organizationalUnit
objectclass: top
ou: ditcontentrules
dn: ou=ditStructureRules, cn=test, ou=schema
objectclass: organizationalUnit
objectclass: top
ou: ditstructurerules
dn: ou=matchingRules, cn=test, ou=schema
objectclass: organizationalUnit
objectclass: top
ou: matchingrules
dn: ou=matchingRuleUse, cn=test, ou=schema
objectclass: organizationalUnit
objectclass: top
ou: matchingruleuse
dn: ou=nameForms, cn=test, ou=schema
objectclass: organizationalUnit
objectclass: top
ou: nameforms
dn: ou=normalizers, cn=test, ou=schema
objectclass: organizationalUnit
objectclass: top
ou: normalizers
dn: ou=objectClasses, cn=test, ou=schema
objectclass: organizationalUnit
objectclass: top
ou: objectClasses
dn: m-oid=1.2.826.0.1.2221664.8.2.4, ou=objectClasses, cn=test, ou=schema
objectclass: metaObjectClass
objectclass: metaTop
objectclass: top
m-oid: 1.2.826.0.1.2221664.8.2.4
m-name: ssoApplicationAssociation
m-description: Single Sign On Application Association
m-supObjectClass: top
m-must: applicationId
dn: ou=syntaxCheckers, cn=test, ou=schema
objectclass: organizationalUnit
objectclass: top
ou: syntaxcheckers
dn: ou=syntaxes, cn=test, ou=schema
objectclass: organizationalUnit
objectclass: top
ou: syntaxes
---------------------------------- test.schema ----------------------------------
# test
# Generated by LDAP Studio on 19 December 2007 12:21:37
attributetype ( 1.2.826.0.1.2221664.8.1.8
NAME ( 'aid' 'applicationId' )
DESC 'Application identifier'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)
objectclass ( 1.2.826.0.1.2221664.8.2.4
NAME 'ssoApplicationAssociation'
DESC 'Single Sign On Application Association'
SUP top
STRUCTURAL
MUST applicationId
)
| |
| Alex Karasulu 2007-12-19, 1:11 pm |
| Hey Simon,
Thanks for finding this. And I looked in JIRA for something similar but I
could not find anything so you must have stepped on a new bug.
Can you do a few more things for this issue so we can test and resolve it:
(1) See if the problem in the present trunk
(2) Report your findings in a JIRA
(3) Create a new test for core-integ with an @Ignore annotation for now.
(4) Attach this test and what data you need to include to your JIRA issue.
Thanks,
Alex
On Dec 19, 2007 9:44 AM, <Simon.Temple-bNHniqfy2KDk7dXyY5I9mNBPR1lH4CV8@public.gmane.org> wrote:
> Using LDAP Studio 0.8.0 I create a new child entry beneath:
> uid=admin,ou=system. I then restart DS. Following the restart, if I try to
> expand the node uid=admin,ou=system to show the child entry I created I get
> an error:
>
> LDAP: error code 54 - failed on search operation: Unexpected
> exception.
>
> I do not get this error prior to the restart. There are no errors in the
> server side log. (log4j.rootCategory=WARN)
>
>
> ** This only appears to be problem when I create the child entry using
> an objectClass I have defined in a custom schema which I load via an LDIF.
>
> i.e. It's not a problem if I stick to entries made up of objectClasses
> that are part of the 'Bootstrap Schema'
>
> To re-create this, simply used the LDIF I have embedded in this mail and
> create a child entry of class: ssoApplicationAssociation beneath
> uid=admin,ou=system (The LDIF was creating using LDAP Studio from the
> attached 'OpenLDAP Style' Schema.)
>
> Is this a defect, has a JIRA entry already been created for this?
>
> Many Thanks
>
> Simon Temple
>
> (Using: apacheds-server-1.5.1-setup.exe on Windows 2003 Server using
> jdk1.5.0_11)
>
> ---------------------------------- test.ldif----------------------------------
> # test
> # Generated by LDAP Studio on 19 December 2007 12:41:08
>
> dn: cn=test, ou=schema
> objectclass: metaSchema
> objectclass: top
> cn: test
> m-dependencies: system
>
> dn: ou=attributeTypes, cn=test, ou=schema
> objectclass: organizationalUnit
> objectclass: top
> ou: attributetypes
>
> dn: m-oid=1.2.826.0.1.2221664.8.1.8, ou=attributeTypes, cn=test, ou=schema
> objectclass: metaAttributeType
> objectclass: metaTop
> objectclass: top
> m-oid: 1.2.826.0.1.2221664.8.1.8
> m-name: aid
> m-name: applicationId
> m-description: Application identifier
> m-equality: caseIgnoreMatch
> m-substr: caseIgnoreSubstringsMatch
> m-syntax: 1.3.6.1.4.1.1466.115.121.1.15
>
> dn: ou=comparators, cn=test, ou=schema
> objectclass: organizationalUnit
> objectclass: top
> ou: comparators
>
> dn: ou=ditContentRules, cn=test, ou=schema
> objectclass: organizationalUnit
> objectclass: top
> ou: ditcontentrules
>
> dn: ou=ditStructureRules, cn=test, ou=schema
> objectclass: organizationalUnit
> objectclass: top
> ou: ditstructurerules
>
> dn: ou=matchingRules, cn=test, ou=schema
> objectclass: organizationalUnit
> objectclass: top
> ou: matchingrules
>
> dn: ou=matchingRuleUse, cn=test, ou=schema
> objectclass: organizationalUnit
> objectclass: top
> ou: matchingruleuse
>
> dn: ou=nameForms, cn=test, ou=schema
> objectclass: organizationalUnit
> objectclass: top
> ou: nameforms
>
> dn: ou=normalizers, cn=test, ou=schema
> objectclass: organizationalUnit
> objectclass: top
> ou: normalizers
>
> dn: ou=objectClasses, cn=test, ou=schema
> objectclass: organizationalUnit
> objectclass: top
> ou: objectClasses
>
> dn: m-oid=1.2.826.0.1.2221664.8.2.4, ou=objectClasses, cn=test, ou=schema
> objectclass: metaObjectClass
> objectclass: metaTop
> objectclass: top
> m-oid: 1.2.826.0.1.2221664.8.2.4
> m-name: ssoApplicationAssociation
> m-description: Single Sign On Application Association
> m-supObjectClass: top
> m-must: applicationId
>
> dn: ou=syntaxCheckers, cn=test, ou=schema
> objectclass: organizationalUnit
> objectclass: top
> ou: syntaxcheckers
>
> dn: ou=syntaxes, cn=test, ou=schema
> objectclass: organizationalUnit
> objectclass: top
> ou: syntaxes
> ---------------------------------- test.schema----------------------------------
> # test
> # Generated by LDAP Studio on 19 December 2007 12:21:37
>
> attributetype ( 1.2.826.0.1.2221664.8.1.8
> NAME ( 'aid' 'applicationId' )
> DESC 'Application identifier'
> EQUALITY caseIgnoreMatch
> SUBSTR caseIgnoreSubstringsMatch
> SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
> )
>
> objectclass ( 1.2.826.0.1.2221664.8.2.4
> NAME 'ssoApplicationAssociation'
> DESC 'Single Sign On Application Association'
> SUP top
> STRUCTURAL
> MUST applicationId
> )
>
| |
| Emmanuel Lecharny 2007-12-19, 7:11 pm |
| Hi,
I'm just wondering if using Studio 1.0.1 could help? 0.8 is pretty
outdated ...
Alex Karasulu wrote:
> Hey Simon,
>
> Thanks for finding this. And I looked in JIRA for something similar
> but I could not find anything so you must have stepped on a new bug.
>
> Can you do a few more things for this issue so we can test and resolve
> it:
>
> (1) See if the problem in the present trunk
> (2) Report your findings in a JIRA
> (3) Create a new test for core-integ with an @Ignore annotation for now.
> (4) Attach this test and what data you need to include to your JIRA
> issue.
>
> Thanks,
> Alex
>
> On Dec 19, 2007 9:44 AM, <Simon.Temple-bNHniqfy2KDk7dXyY5I9mNBPR1lH4CV8@public.gmane.org
> <mailto:Simon.Temple-bNHniqfy2KDk7dXyY5I9mNBPR1lH4CV8@public.gmane.org>> wrote:
>
> Using LDAP Studio 0.8.0 I create a new child entry beneath:
> uid=admin,ou=system. I then restart DS. Following the restart,
> if I try to expand the node uid=admin,ou=system to show the child
> entry I created I get an error:
>
> LDAP: error code 54 - failed on search operation: Unexpected
> exception.
>
> I do not get this error prior to the restart. There are no errors
> in the server side log. (log4j.rootCategory=WARN)
>
>
> ** This only appears to be problem when I create the
> child entry using an objectClass I have defined in a custom schema
> which I load via an LDIF.
>
> i.e. It's not a problem if I stick to entries made up of
> objectClasses that are part of the 'Bootstrap Schema'
>
> To re-create this, simply used the LDIF I have embedded in this
> mail and create a child entry of class: ssoApplicationAssociation
> beneath uid=admin,ou=system (The LDIF was creating using LDAP
> Studio from the attached 'OpenLDAP Style' Schema.)
>
> Is this a defect, has a JIRA entry already been created for this?
>
> Many Thanks
>
> Simon Temple
>
> (Using: apacheds-server-1.5.1-setup.exe on Windows 2003 Server
> using jdk1.5.0_11)
>
> ---------------------------------- test.ldif
> ----------------------------------
> # test
> # Generated by LDAP Studio on 19 December 2007 12:41:08
>
> dn: cn=test, ou=schema
> objectclass: metaSchema
> objectclass: top
> cn: test
> m-dependencies: system
>
> dn: ou=attributeTypes, cn=test, ou=schema
> objectclass: organizationalUnit
> objectclass: top
> ou: attributetypes
>
> dn: m-oid=1.2.826.0.1.2221664.8.1.8, ou=attributeTypes, cn=test,
> ou=schema
> objectclass: metaAttributeType
> objectclass: metaTop
> objectclass: top
> m-oid: 1.2.826.0.1.2221664.8.1.8
> m-name: aid
> m-name: applicationId
> m-description: Application identifier
> m-equality: caseIgnoreMatch
> m-substr: caseIgnoreSubstringsMatch
> m-syntax: 1.3.6.1.4.1.1466.115.121.1.15
>
> dn: ou=comparators, cn=test, ou=schema
> objectclass: organizationalUnit
> objectclass: top
> ou: comparators
>
> dn: ou=ditContentRules, cn=test, ou=schema
> objectclass: organizationalUnit
> objectclass: top
> ou: ditcontentrules
>
> dn: ou=ditStructureRules, cn=test, ou=schema
> objectclass: organizationalUnit
> objectclass: top
> ou: ditstructurerules
>
> dn: ou=matchingRules, cn=test, ou=schema
> objectclass: organizationalUnit
> objectclass: top
> ou: matchingrules
>
> dn: ou=matchingRuleUse, cn=test, ou=schema
> objectclass: organizationalUnit
> objectclass: top
> ou: matchingruleuse
>
> dn: ou=nameForms, cn=test, ou=schema
> objectclass: organizationalUnit
> objectclass: top
> ou: nameforms
>
> dn: ou=normalizers, cn=test, ou=schema
> objectclass: organizationalUnit
> objectclass: top
> ou: normalizers
>
> dn: ou=objectClasses, cn=test, ou=schema
> objectclass: organizationalUnit
> objectclass: top
> ou: objectClasses
>
> dn: m-oid=1.2.826.0.1.2221664.8.2.4, ou=objectClasses, cn=test,
> ou=schema
> objectclass: metaObjectClass
> objectclass: metaTop
> objectclass: top
> m-oid: 1.2.826.0.1.2221664.8.2.4
> m-name: ssoApplicationAssociation
> m-description: Single Sign On Application Association
> m-supObjectClass: top
> m-must: applicationId
>
> dn: ou=syntaxCheckers, cn=test, ou=schema
> objectclass: organizationalUnit
> objectclass: top
> ou: syntaxcheckers
>
> dn: ou=syntaxes, cn=test, ou=schema
> objectclass: organizationalUnit
> objectclass: top
> ou: syntaxes
> ---------------------------------- test.schema
> ----------------------------------
> # test
> # Generated by LDAP Studio on 19 December 2007 12:21:37
>
> attributetype ( 1.2.826.0.1.2221664.8.1.8
> NAME ( 'aid' 'applicationId' )
> DESC 'Application identifier'
> EQUALITY caseIgnoreMatch
> SUBSTR caseIgnoreSubstringsMatch
> SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
> )
>
> objectclass ( 1.2.826.0.1.2221664.8.2.4
> NAME 'ssoApplicationAssociation'
> DESC 'Single Sign On Application Association'
> SUP top
> STRUCTURAL
> MUST applicationId
> )
>
>
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
| |
| Simon.Temple-bNHniqfy2KDk7dXyY5I9mNBPR1lH4CV8@ 2007-12-21, 7:11 am |
| Alex,
I have rebuilt my stuff to run with a 1.5.2-SNAPSHOT and can confirm thisproblem does not exist using the latest trunk.
How do you wish me to proceed?
- SimonT
19 December 2007 16:55
To: "Apache Directory Developers List" <dev-aYN4UCa7k1r1N9kud6OZbmD2FQJk+8+b@public.gmane.org>
cc:
From: "Alex Karasulu" <akarasulu-1oDqGaOF3Lkdnm+yROfE0A@public.gmane.org>
Subject: Re: Possible defect in 1.5.1: error code 54 - failed on search operation
Hey Simon,
Thanks for finding this. And I looked in JIRA for something similar but I could not find anything so you must have stepped on a new bug.
Can you do a few more things for this issue so we can test and resolve it:
(1) See if the problem in the present trunk
(2) Report your findings in a JIRA
(3) Create a new test for core-integ with an @Ignore annotation for now.
(4) Attach this test and what data you need to include to your JIRA issue.
Thanks,
Alex
On Dec 19, 2007 9:44 AM, <Simon.Temple-bNHniqfy2KDk7dXyY5I9mNBPR1lH4CV8@public.gmane.org> wrote:
Using LDAP Studio 0.8.0 I create a new child entry beneath: uid=admin,ou=system. I then restart DS. Following the restart, if I try to expand the node uid=admin,ou=system to show the child entry I created I get an error:
LDAP: error code 54 - failed on search operation: Unexpected exception.
I do not get this error prior to the restart. There are no errors in theserver side log. (log4j.rootCategory=WARN)
** This only appears to be problem when I create the child entry using anobjectClass I have defined in a custom schema which I load via an LDIF.
i.e. It's not a problem if I stick to entries made up of objectClasses that are part of the 'Bootstrap Schema'
To re-create this, simply used the LDIF I have embedded in this mail and create a child entry of class: ssoApplicationAssociation beneath uid=admin,ou=system (The LDIF was creating using LDAP Studio from the attached 'OpenLDAP Style' Schema.)
Is this a defect, has a JIRA entry already been created for this?
Many Thanks
Simon Temple
(Using: apacheds-server-1.5.1-setup.exe on Windows 2003 Server using jdk1.5.0_11)
---------------------------------- test.ldif ----------------------------------
# test
# Generated by LDAP Studio on 19 December 2007 12:41:08
dn: cn=test, ou=schema
objectclass: metaSchema
objectclass: top
cn: test
m-dependencies: system
dn: ou=attributeTypes, cn=test, ou=schema
objectclass: organizationalUnit
objectclass: top
ou: attributetypes
dn: m-oid=1.2.826.0.1.2221664.8.1.8, ou=attributeTypes, cn=test, ou=schema
objectclass: metaAttributeType
objectclass: metaTop
objectclass: top
m-oid: 1.2.826.0.1.2221664.8.1.8
m-name: aid
m-name: applicationId
m-description: Application identifier
m-equality: caseIgnoreMatch
m-substr: caseIgnoreSubstringsMatch
m-syntax: 1.3.6.1.4.1.1466.115.121.1.15
dn: ou=comparators, cn=test, ou=schema
objectclass: organizationalUnit
objectclass: top
ou: comparators
dn: ou=ditContentRules, cn=test, ou=schema
objectclass: organizationalUnit
objectclass: top
ou: ditcontentrules
dn: ou=ditStructureRules, cn=test, ou=schema
objectclass: organizationalUnit
objectclass: top
ou: ditstructurerules
dn: ou=matchingRules, cn=test, ou=schema
objectclass: organizationalUnit
objectclass: top
ou: matchingrules
dn: ou=matchingRuleUse, cn=test, ou=schema
objectclass: organizationalUnit
objectclass: top
ou: matchingruleuse
dn: ou=nameForms, cn=test, ou=schema
objectclass: organizationalUnit
objectclass: top
ou: nameforms
dn: ou=normalizers, cn=test, ou=schema
objectclass: organizationalUnit
objectclass: top
ou: normalizers
dn: ou=objectClasses, cn=test, ou=schema
objectclass: organizationalUnit
objectclass: top
ou: objectClasses
dn: m-oid=1.2.826.0.1.2221664.8.2.4, ou=objectClasses, cn=test, ou=schema
objectclass: metaObjectClass
objectclass: metaTop
objectclass: top
m-oid: 1.2.826.0.1.2221664.8.2.4
m-name: ssoApplicationAssociation
m-description: Single Sign On Application Association
m-supObjectClass: top
m-must: applicationId
dn: ou=syntaxCheckers, cn=test, ou=schema
objectclass: organizationalUnit
objectclass: top
ou: syntaxcheckers
dn: ou=syntaxes, cn=test, ou=schema
objectclass: organizationalUnit
objectclass: top
ou: syntaxes
---------------------------------- test.schema ----------------------------------
# test
# Generated by LDAP Studio on 19 December 2007 12:21:37
attributetype ( 1.2.826.0.1.2221664.8.1.8
NAME ( 'aid' 'applicationId' )
DESC 'Application identifier'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)
objectclass ( 1.2.826.0.1.2221664.8.2.4
NAME 'ssoApplicationAssociation'
DESC 'Single Sign On Application Association'
SUP top
STRUCTURAL
MUST applicationId
)
| |
| Alex Karasulu 2007-12-21, 1:11 pm |
| On Dec 21, 2007 7:09 AM, <Simon.Temple-bNHniqfy2KDk7dXyY5I9mNBPR1lH4CV8@public.gmane.org> wrote:
> Alex,
>
> I have rebuilt my stuff to run with a 1.5.2-SNAPSHOT and can confirm this
> problem does not exist using the latest trunk.
>
> How do you wish me to proceed?
>
Hey that's good news. I guess we can just ignore this and try to push for
1.5.2 to come out. You cool with working with the trunk?
Alex
> *19 December 2007 16:55
> To: "Apache Directory Developers List" <dev-aYN4UCa7k1r1N9kud6OZbmD2FQJk+8+b@public.gmane.org>
> cc:
> From: "Alex Karasulu" <akarasulu-1oDqGaOF3Lkdnm+yROfE0A@public.gmane.org>
> Subject: Re: Possible defect in 1.5.1: error code 54 - failed on search
> operation*
>
> Hey Simon,
>
> Thanks for finding this. And I looked in JIRA for something similar but I
> could not find anything so you must have stepped on a new bug.
>
> Can you do a few more things for this issue so we can test and resolve it:
>
>
> (1) See if the problem in the present trunk
> (2) Report your findings in a JIRA
> (3) Create a new test for core-integ with an @Ignore annotation for now.
> (4) Attach this test and what data you need to include to your JIRA issue.
>
>
> Thanks,
> Alex
>
> On Dec 19, 2007 9:44 AM, <Simon.Temple-bNHniqfy2KDk7dXyY5I9mNBPR1lH4CV8@public.gmane.org> wrote:
>
>
>
|
|
|
|
|