IDP V3: LockTimeoutException with remote PG DB
TISSOT Jacques
jacques.tissot at unifr.ch
Tue Oct 13 05:29:22 EDT 2015
I found something related to this raise of errors:
The problem happens every 10 minutes. And which component is scheduled every 10' ?
./global.xml: idp.storage.cleanupInterval:PT10M
I changed the interval to 15M .... --> every 15 '
I changed the interval to 5M ... --> every 5'
Lower the interval to 5' don't solve the problem. It just occurs every 5'.
I could schedule this to 1 day, so that it occurs during the night, huh?
What is running behind this storage.cleanup, making a lot of "SELECT waiting"?
Thanks for help
Jacques Tissot
> -----Original Message-----
> From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Cantor,
> Scott
> Sent: jeudi 8 octobre 2015 15:47
> To: Shib Users
> Subject: Re: IDP V3: LockTimeoutException with remote PG DB
>
> On 10/8/15, 9:27 AM, "users on behalf of Marvin Addison" <users-
> bounces at shibboleth.net on behalf of marvin.addison at gmail.com> wrote:
>
> >Your comment about the problem not showing up when the DB is local is
> puzzling. Perhaps there's some subtle but very bad behavior when
> application locks are held marginally longer, which I would expect would
> be the case for connections to a remote host.
>
> At least with regard to the use of the database for persistent ID storage,
> and not sessions, I did discover that the default query timeout on that
> storage plugin was 0 (infinite).
>
> We clearly still have code with inappropriate timeout defaults, so we have
> more work to do on that front, but I'm fixing that particular bug in the
> broader rewrite of that plugin to address the race conditions.
>
> But obviously, using a timeout simply moves the problem to an error
> generating a stored ID. Ultimately the fault is with the network or
> database.
>
> -- Scott
>
> --
> To unsubscribe from this list send an email to users-
> unsubscribe at shibboleth.net
More information about the users
mailing list