UUID for myComputedId

[Joshua Brodie]

Hi Scott.

Thank you for your reply -- you and Nate are helping me understand the
options.

For the StoredID -- we have retries set as below -- but we still getting 30
or so not getting through per day with retries exhausted (we are currently
transferring services from a vendor SSO to shibboleth --- so hence the new
entries).

Is there a setting to gracefully fail the StoredID if all the retries are
exhausted? We don't absolutely require the StoredID in all cases. At the
moment, when retries exhausted, the browser is redirected to target service
without any attributes (which is the kerfuffle).

<resolver:DataConnector id="myStoredId" xsi:type="dc:StoredId"
generatedAttributeID="persistentID" sourceAttributeID=
"%{idp.persistentId.sourceAttribute}"  queryTimeout="PT20S"
transactionRetries="20" retryableErrors="72000 23000">

<resolver:Dependency ref="%{idp.persistentId.sourceAttribute}" />

<dc:BeanManagedConnection>OracleDataSource</dc:BeanManagedConnection>

    </resolver:DataConnector>


On Tue, 31 Jul 2018 at 12:22, Cantor, Scott <cantor.2 at osu.edu> wrote:

> > Our StoredID are in format UUID -- is it possible to generate UUID via
> > ComputedID?
>
> No, certainly not, it's a hash.
>
> If the code is hardwiring a certain number of retries I'm sure that can be
> relaxed and made settable, I don't recall whether it was or not. There's
> nothing the code can do if Oracle keeps refusing to accept the
> transactions, all it can do is keep trying. But it can't just try forever.
>
> -- Scott
>
> --
> For Consortium Member technical support, see
> https://wiki.shibboleth.net/confluence/x/coFAAg
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20180731/b332e327/attachment.html>