postgress errors during oauth 2.0 performance testing
Hi everyone,
We encountered a recurring postgres error during a basic performance test of our oauth 2.0 authorization code grant_type flow. The below errors repeatedly occur while testing the oauth login page, the generation of the auth code, generation of access_token, the refresh token functionality, and the revoke access token functionality. The calls are made in succession (mimicking a typical use case flow order).
The test is run with only 1 concurrent user, at 1-5 TPS, and the test duration is 5 minutes.
2015-04-28 02:05:50,886 org: env: main WARN i.a.a.s.a.ServerBootstrapService - ServerBootstrapServiceImpl$1$4.execute() : Exception occured while making a query: select pg_last_xlog_receive_location() Exception: Could not get JDBC Connection; nested exception is org.apache.commons.dbcp.SQLNestedException: Cannot create PoolableConnectionFactory (Connection refused. Check that the hostname and port are correct and that the postmaster is accepting TCP/IP connections.)
These errors do not occur for our QC functional testing (very low volume).
Has anyone seen these errors before, and/or does anyone know if we should be worried about our infrastructure or applications?
Best, Chris
Hi @Chris Covney is it happening on any other proxy or just the OAuth proxy? This is interesting as postgres is not really used besides for capturing analytics or if a StatisticsCollector policy is used. The OAuth tokens are persisted in the underlying cassandra tier. @Vinit Mehta
Hi Prithpal,
This error occurs for all our proxies. We do have the statistics collector policy in each of our proxies, but we are only collecting 3-4 metrics per proxy, not much data
Best Answer
Hi @Chris Covney could point to an issue potentially associated with replication. Is the postgres db installed in a master / slave topology? Would recommend to log a ticket with Apigee Support and have your configuration reviewed.
Hi Prithpal,
That is a very good point. Our postgres DB is installed in a master/slave topology, but we've never had to fail over to the slave instance. I will log a ticket to look into the config. Thanks for the help!
