ContextSource pool problem when using DirSync

[wsekulskiInteca]

trafficstars

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]

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.