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