LDAP-153: Spring Pooling does not support sorting ; Cannot call setRequestControls on a pooled context

[spring-projects-issues]

Thomas B(Migrated from LDAP-153) said:

When one use spring’s PoolingContextSource and Ldap sorting (through “SortControlDirContextProcessor”) or result limit (throuh “PagedResultsRequestControl”) this is causing a deadly UnsupportedOperationException(“Cannot call setRequestControls on a pooled context”).
Sun’s build in ‘supports’ this kind of controls (but see http://forum.springframework.org/showthread.php?p=213254 )

My guess joins Rasky’s explaination : Control state is kept on the server side wich means that sun’s impl is probably broken but at least request keep flowing.
Rasky’s idea of clearing the controls while returning connexion to the pool should be fine but how do we know the initial server state (if any : I don’t know the LDAProtocol very well)

Here is the stack trace
java.lang.UnsupportedOperationException: Cannot call setRequestControls on a pooled context
at org.springframework.ldap.pool.DelegatingLdapContex t.setRequestControls(DelegatingLdapContext.java:18 5)
at org.springframework.ldap.control.AbstractRequestCo ntrolDirContextProcessor.preProcess(AbstractReques tControlDirContextProcessor.java:83)
at org.springframework.ldap.core.support.AggregateDir ContextProcessor.preProcess(AggregateDirContextPro cessor.java:75)
at org.springframework.ldap.core.LdapTemplate.search( LdapTemplate.java:271)
at org.springframework.ldap.core.LdapTemplate.search( LdapTemplate.java:234)

[spring-projects-issues]

Thomas B said:

By the way, LDAP-114 might be linked with this issue

[spring-projects-issues]

Eric Dalquist said:

Thomas,

I had authored the original ldap connection pooling code and had marked any method that changed the state of the underlying connection as unsupported. Sun’s pool allows all of these methods but if the calling code doesn’t reset the changes on close (returning the pooled connection) you get VERY unpredictable results, the most obvious case is when using LDAP for auth via simple binds or rebinds. There has been talk in the past about having the pooling wrapper track changes and back them out when the connection is returned and I think that is likely the best viable option.

Another option would be to extend the default pool to have a pool that acts more like Sun’s and allows any methods on the context and just let the client code deal with any connection state management.

[spring-projects-issues]

Mattias Hellborg Arthursson said:

I think we should fix this. The simplest way of going about it would be just to empty the request controls before returning a connection to the pool.

[spring-projects-issues]

Ulrik Sandberg said:

Eric, could you elaborate on “having the pooling wrapper track changes and back them out when the connection is returned”?

[spring-projects-issues]

Ulrik Sandberg said:

I have added a MutablePoolingContextSource that creates LDAP contexts that allow request controls to be set. I have verified that paged results works with the following pooling configuration:

    <bean id="poolingContextSource" class="org.springframework.ldap.pool.factory.MutablePoolingContextSource">
        <property name="contextSource" ref="contextSource" />
        <property name="dirContextValidator">
            <bean class="org.springframework.ldap.pool.validation.DefaultDirContextValidator" />
        </property>
        <property name="maxTotal" value="1" />
        <property name="testOnBorrow" value="true"/>
        <property name="testWhileIdle" value="true"/>
    </bean> 

```
<bean id="ldapTemplate" class="org.springframework.ldap.core.LdapTemplate">
    <constructor-arg ref="poolingContextSource" />
</bean>
```

The only difference to a standard pooling configuration is that the size is 1 and the pooling context source class is MutablePoolingContextSource instead of PoolingContextSource.
bc..