[Scala 2.5.4] org.postgresql.util.PSQLException: FATAL: sorry, too many clients already: Timeout

398 views
Skip to first unread message

Michael Slinn

unread,
Aug 1, 2016, 6:16:53 PM8/1/16
to Play framework dev
This is weird. I have a multiproject Play webapp which does not use the Play DB integration components (it does not use jdbc or play-slick). These are the database-related dependencies:

"com.zaxxer"          %  "HikariCP"                 % "2.3.12"
"org.postgresql"      %  "postgresql"               % "9.4.1209"
"com.micronautics"    %% "scalacourses-slick-utils" % "3.1.1"
"com.typesafe.slick"  %% "slick"                    % "3.1.1"
"com.typesafe.slick"  %% "slick-hikaricp"           % "3.1.1" exclude("com.zaxxer", "HikariCP-java6")


The SBT subprojects are:

root
  cadenza
    service
      model
        silhouette
          persistence (nonPlay)

When I run tests on the persistence subproject, I can hammer the database all day without a problem. When I run the root Play project, the eagerly loaded database cache preloader I wrote fetches data from 9 tables in parallel, which I expect will use 9 connections, then after a delay I get "org.postgresql.util.PSQLException: FATAL: sorry, too many clients already: Timeout after 1000ms of waiting for a connection." The simplified, single-project version of the app works fine. Here is the database configuration:

postgres = {
  dataSourceClass = "org.postgresql.ds.PGSimpleDataSource"
  leakDetectionThreshold = 2000
  properties = {
    databaseName = ${?DB}
    password = ${?PGPASSWORD}
    serverName=${?PGSERVER}
    user = ${?USERID}
  }
}


Stepping through the cache preload sequence I saw this appear:

[warn] c.z.h.p.LeakTask - Connection leak detection triggered for connection org.postgresql.jdbc.PgConnection@3fe496bb, stack trace follows
java.lang.Exception: Apparent connection leak detected
        at slick.jdbc.hikaricp.HikariCPJdbcDataSource.createConnection(HikariCPJdbcDataSource.scala:12)
        at slick.jdbc.JdbcBackend$BaseSession.conn$lzycompute(JdbcBackend.scala:415)
        at slick.jdbc.JdbcBackend$BaseSession.conn(JdbcBackend.scala:414)
        at slick.jdbc.JdbcBackend$SessionDef$class.prepareStatement(JdbcBackend.scala:297)
        at slick.jdbc.JdbcBackend$BaseSession.prepareStatement(JdbcBackend.scala:407)


Suggestions?

Mike

James Roper

unread,
Aug 1, 2016, 8:53:46 PM8/1/16
to Michael Slinn, Play framework dev
What I would do is set a break point on the connection pool acquisition method, and see what's acquiring those connections.

--
You received this message because you are subscribed to the Google Groups "Play framework dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framework-...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--
James Roper
Software Engineer

Lightbend – Build reactive apps!
Twitter: @jroper

James Roper

unread,
Aug 2, 2016, 1:07:47 AM8/2/16
to Mike Slinn, Play framework dev
I'd be sticking a break point in the implementation of db.run <- that's what triggers a connection to be taken out of the pool.

On 2 August 2016 at 11:24, Mike Slinn <msl...@gmail.com> wrote:
None of my code ever sees a connection, those are indirectly managed by Slick 3.1.1's DBIOAction run methods. Not sure how to approach the debugging of the trampolines.

Mike
Reply all
Reply to author
Forward
0 new messages