We're updating the issue view to help you get more done. 

Use paged results in LDAP queries

Description

LDAP servers can page results from a query, allowing for extremely large queries to be fulfilled efficiently. Openfire should be modified to use this method instead of relying on a single "large page" to return results.

Environment

LDAP systems with large numbers of users

Acceptance Test - Entry

None

Activity

Show:
Andreas Sieferlinger
March 14, 2008, 4:17 PM

A short example:
If i search in groups for 'csm' then i get an empty result page, but on the top there are 17 pages shown, so i think this is also an issue related to the paged results, 'cause we have about 40.000 groups

Andreas Sieferlinger
March 14, 2008, 4:42 PM

I also experienced the Problem that If i enable Contact-List sharing the server takes about 30 seconds and only adds 4 from 16 users to the shared roster
I first thought that this 4 users are only users which are in the first 1000 of results, but they're not.
That's really a problem, do the sharing for all 16 users by hand is some work.

Daniel Henninger
March 14, 2008, 7:09 PM

That actually shouldn't be the case. The searches do "true ldap searches", so the paged results should be irrelavent assuming you aren't getting back a lot of pages of csm results. =) Anyone else running into problems with searching?

As for the contact list sharing, that's something I plan on looking into. It's kind of bizarre that it takes that long. My assumption is that it's doing a getUsers search even if it doesn't have to. It's hard to say without trying it some more though and watching what occurs.

Daniel Henninger
March 29, 2008, 2:25 AM

Trevor, do you know of a control id for the ranged search results for attributes? In other words, is there a way I could ask the LDAP server "hey, do you support this?" and then use it, similar to the other features?

Trevor Scroggins
March 29, 2008, 11:22 AM

According to Microsoft's documentation and the (expired) Internet draft "Incremental Retrieval of Multi-valued Properties" <http://www.ietf.org/proceedings/02mar/I-D/draft-kashi-incremental-00.txt>, supportedControl (incorrectly identified in the draft but correctly indentified here) should contain 1.2.840.113556.1.4.802. As far as I know, Active Directory is the only directory that supports this option.

Not all clients correctly parse the results, as the option is not, strictly spearking, implemented in a standard way. The JNDI LDAP provider should work correctly, though.

Assignee

Daniel Henninger

Reporter

Jay Kline

Labels

None

Expected Effort

None

Ignite Forum URL

None

Components

Fix versions

Priority

Minor
Configure