Announcement Announcement Module
Collapse
No announcement yet.
2nd Paged Search results in error code 53 Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • 2nd Paged Search results in error code 53

    Hello,
    I'm a relatively new Spring user in the process of evaluating the use of Spring-LDAP's PagedResults feature for use in the project I'm working on. I've set up a simple example to perform this evaluation, but I can't get it work properly.

    The issue is that the first request works fine, but the second request is producing an ldap error 53 - unwilling to perform.

    I'm using Spring-LDAP 1.3 and Tivoli Directory Server 6.1 (which I think supports paged search controls)

    I initially set this all up using a pooled context source, etc... but in order to isolate the problem I've made it much simpler... Here is how my example is set up:

    Code:
    <bean id="pagedContextSource" class="org.springframework.ldap.core.support.LdapContextSource">
            <property name="urls">
                    <value>$ctx{common.ldap.urls}</value>
            </property>
            <property name="base" value="ou=Users,c=us"/>
            <property name="userDn">
                    <value>$ctx{common.ldap.user}</value>
            </property>
            <property name="password">
                    <value>$ctx{common.ldap.password}</value>
            </property>
            <property name="pooled" value="false" />
    </bean>
    
    <bean id="pagedLdapTemplate" class="org.springframework.ldap.core.LdapTemplate">
            <constructor-arg ref="pagedContextSource" />
    </bean>
    The search method and calling code are as follows:
    Code:
    public PagedResult pagedSearch(Filter filter, PagedResultsCookie cookie)
    {
            final int PAGE_SIZE = 100;
            PagedResultsDirContextProcessor pageProcessor = new PagedResultsDirContextProcessor(PAGE_SIZE, cookie);
    
            SearchControls searchControls = new SearchControls();
            searchControls.setSearchScope(SearchControls.SUBTREE_SCOPE);
            searchControls.setReturningObjFlag(true);
    
            List people = pagedLdapTemplate.search("", filter, searchControls, new CustomContextMapper(clientAbbrev, false), pageProcessor);
    
            return new PagedResult(people, pageProcessor.getCookie());
    }
    
    //**snippet of calling method**
    
    PagedResult result = customPersonDao.pagedSearch(new LikeFilter("uid","*"), null);
    
    PagedResultsCookie prCookie = result.getCookie();
    
    List<CustomPerson> people1 = (List<CustomPerson>) result.getResultList();
    
    Iterator people1Iter = people1.iterator();
    while (people1Iter.hasNext()){
            CustomPerson person = (CustomPerson) people1Iter.next();
            System.out.println("dn: " + person.getDn().toString());
    }
    
    PagedResult result2 = customPersonDao.pagedSearch(new LikeFilter("uid","*"), prCookie);
    
    List<CustomPerson> people2 = (List<CustomPerson>) result2.getResultList();
    
    Iterator people2Iter = people2.iterator();
    while (people2Iter.hasNext()){
            CustomPerson person = (CustomPerson) people2Iter.next();
            System.out.println("dn: " + person.getDn().toString());
    }
    
    //** end snippet **
    The resulting output prints the DNs of the first 100 users correctly, but then it throws an OperationNotSupportedException trying to execute the second search -- citing Ldap error code 53 - "unwilling to perform"

    I have enabled LDAP audit to view the requests on the server-side and found the following output:

    Code:
    AuditV3--2009-12-30-10:07:52.536+00:00--V3 SSL Bind--bindDN: cn=root--client: 192.168.188.6:61396--connectionID: 26--received: 2009-12-30-10:07:52.536+00:00--Success
    name: cn=root
    authenticationChoice: simple
    Admin Acct Status: Not Locked
    
    AuditV3--2009-12-30-10:07:52.552+00:00--V3 SSL Search--bindDN: cn=root--client: 192.168.188.6:61396--connectionID: 26--received: 2009-12-30-10:07:52.538+00:00--Success
    controlType: 2.16.840.1.113730.3.4.2
    criticality: false
    controlType: 1.2.840.113556.1.4.319
    criticality: true
    base: ou=Users,c=us
    scope: wholeSubtree
    derefAliases: derefAlways
    typesOnly: false
    filter: (uid=*)
    
    AuditV3--2009-12-30-10:07:54.037+00:00--V3 SSL Unbind--bindDN: cn=root--client: 192.168.188.6:61396--connectionID: 26--received: 2009-12-30-10:07:54.037+00:00--Success
    
    AuditV3--2009-12-30-10:08:17.462+00:00--V3 SSL Bind--bindDN: cn=root--client: 192.168.188.6:61652--connectionID: 27--received: 2009-12-30-10:08:17.461+00:00--Success
    name: cn=root
    authenticationChoice: simple
    Admin Acct Status: Not Locked
    
    AuditV3--2009-12-30-10:08:17.463+00:00--V3 SSL Search--bindDN: cn=root--client: 192.168.188.6:61652--connectionID: 27--received: 2009-12-30-10:08:17.463+00:00--DSA is unwilling to perform
    controlType: 2.16.840.1.113730.3.4.2
    criticality: false
    controlType: 1.2.840.113556.1.4.319
    criticality: true
    base: ou=Users,c=us
    scope: wholeSubtree
    derefAliases: derefAlways
    typesOnly: false
    filter: (uid=*)
    
    AuditV3--2009-12-30-10:08:17.464+00:00--V3 SSL Unbind--bindDN: cn=root--client: 192.168.188.6:61652--connectionID: 27--received: 2009-12-30-10:08:17.464+00:00--Success
    Note the "DSA is unwilling to perform" message after the second search...

    I get the same behavior whether I use a pooled context or not... but I can't help but wonder if connectionID being different between these requests could be causing the problem.

    Any input would be very much appreciated!

    Thanks,
    Brook

  • #2
    found partial solution... but still need advice

    based on the information in this thread: http://forum.springsource.org/showth...illing+perform

    I was able to use the MutablePoolingContextSource to perform my paged queries because by setting the pool size to 1 I can (pretty much) guarantee that the same connection is used for all of the pages.

    However, having a pool size of one is not going to work for my application...

    So, the question is: Is there a way of ensuring that the same pool member is used for each request in a paged sequence? Or is there some way of modifying the ldap configuration so as to eliminate this requirement of using the same connection?

    Comment

    Working...
    X