Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ContextSource pool problem when using DirSync #534

Open
wsekulskiInteca opened this issue May 29, 2019 · 1 comment
Open

ContextSource pool problem when using DirSync #534

wsekulskiInteca opened this issue May 29, 2019 · 1 comment

Comments

@wsekulskiInteca
Copy link

wsekulskiInteca commented May 29, 2019

java 1.8
spring boot: 2.0.3.RELEASE
spring-ldap-core: 2.3.2.RELEASE

When I use DirSync cookie for control response in one request,
it seems that all other requests called using this ContextSource start using DirSync

test:

public void callQueryAfterDirsync() {
    DirSyncContextProcesor proc = new DirSyncContextProcesor(null);
    getByDirsync(proc);
    SearchControls controls = new SearchControls();
    controls.setTimeLimit(0);
    controls.setCountLimit(0);
    controls.setSearchScope(SearchControls.SUBTREE_SCOPE);
    String [] attr =  {"memberOf"};
    controls.setReturningAttributes(attr);
    List<LdapUser> result = template.search("", "cn=myUser", controls,  userContextMapper);
    System.out.println(result.get(0).getDnAdGroups().toString());
}
    
public List<LdapUser> getByDirsync(DirContextProcessor proc) {
    SearchControls controls = new SearchControls();
    controls.setTimeLimit(0);
    controls.setCountLimit(0);
    controls.setSearchScope(SearchControls.SUBTREE_SCOPE);
    return template.search("", "objectClass=user", controls, userContextMapper, proc);
}

If I call normal search after dirSync search I cannot get memberOf attribute any more

@pavelhoral
Copy link

This is a pretty nasty issue we have come across as well.

We were using Server Side Sorting with one search and it gets persisted on the pooled context. I understand, that this is a side effect of how things work, but this needs to be added as a warning to MutablePoolingContextSource JavaDoc and pooling documentation. When someone mutates the context, the context needs to be either discarded (not sure if possible) or it has to be mutated back before returning it to the pool (i.e. before closing it)... to be honest the architecture of all related components are not offering many tools to handle this and using MutablePoolingContextSource should probably be discouraged at the moment.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants