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

[Daniel W Fisher (JIRA)]

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

Daniel W Fisher commented on SC-170:
------------------------------------

The reason the blockWaitTime wasn't exposed is that it's an implementation detail of the pool and does not exist on the pool config. However, since the only pool implementations supported have this property I would say +1 to adding it. Changing the init method to throw fixes the hang on startup, but a pool could get into a hung state after startup. Setting a blockWaitTime could have benefits there.

{quote}
Dan, can you take a look at the rest of the LDAP data connector config properties and see if there is anything else we should expose but don't?
{quote}
On the pool config we do not expose validateOnCheckIn or validateOnCheckOut, instead we only support periodic validation. I'm not inclined to change that unless someone shows up with a use case for it.

{quote}
My issue is the fail-fast, which is separate.
{quote}
Scott, are you going to file a separate issue for fail-fast?


> 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