[JIRA] Commented: (SC-170) Expose LDAP pool blockWaitTime on VT pool strategy via connector config

[Chad La Joie (JIRA)]

    [ https://issues.shibboleth.net/jira/browse/SC-170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13808#comment-13808 ] 

Chad La Joie commented on SC-170:
---------------------------------

No, I suspect that will cause a problem.  #validate() is called any time the full status page is rendered as the IdP checks to see if the resolver is functional.  That in turn would mean that pool.initialize() would be called more than once which, I suspect, would cause a problem.

> Expose LDAP pool blockWaitTime on VT pool strategy via connector config
> -----------------------------------------------------------------------
>
>                 Key: SC-170
>                 URL: https://issues.shibboleth.net/jira/browse/SC-170
>             Project: Shibboleth Common - Java
>          Issue Type: Improvement
>          Components: Attribute Authority
>    Affects Versions: 1.3.4
>            Reporter: Scott Cantor
>            Assignee: Daniel W Fisher
>         Attachments: vt-ldap-3.3.5-SNAPSHOT-dist.tar.gz
>
>
> If you have a pool configured in the LDAP connector, and the LDAP server doesn't respond or there's a trust-related error preventing connections, the IdP fails to start up but also hangs inside the pool init method waiting for at least one connection to come back. There's a blockWaitTime setting, but it apparently defaults to indefinite wait, and it isn't exposed in our config.
> We should at least expose it via the Pool config schema that wraps the internal VT pool, and use a better default, or perhaps use different defaults based on whether a hard or soft pool is used?
> Daniel also mentioned changing the VT library to throw an exception out if the minimum number of connections can't be set up in the pool.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira