IDP V3: LockTimeoutException with remote PG DB

[Walter Forbes Hoehn (wassa)]

For what it’s worth (probably very little), we have been running with JPA storage using Postgres for several months.  We’ve encountered no problems, either in production or during synthetic load testing.

-Walter


> On Oct 8, 2015, at 8:27 AM, Marvin Addison <marvin.addison at gmail.com> wrote:
> 
> The following observation appears only when IDP is asking PG DB server remotely. I tried different (in global.xml) maxActive and maxIdle jdbc connectors (up to 32) without solving the problem. The problem does not appear when IDP is asking PG DB locally.
> 
> I took some time to attempt to reproduce the error on a test platform, but was unable. It's a pretty synthetic test using a VM with everything (IdP, OpenLDAP, and PG) running on the same box, but I hit it with enough concurrent load that if there were a fundamental problem with the locking code, it should have showed up.
> 
> In particular, I was interested in the interaction of the cleaner process with front-end threads. I turned the session timeout and authn result timeouts to 1m, turned the cleaner poll process down to 30s, and ran the test for 5m, which ought to have been long enough to mix in several cleaner processes with request threads. I simply couldn't generate failures.
> 
> I should note that I used HikariCP for the pooling library with default settings (10 connections max).
> 
> 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. I don't have any more time to spend on further investigation at the moment, but I believe we'll need more data to investigate further.
> 
> M
> 
> -- 
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net