Just out of curiosity, is this still an issue for folks on this thread? Were you able to resolve your issues by setting up a connection pool in Tomcat using Alan Orth's instructions? The reason I ask is that when we upgraded from 5.4 to 6.3 we also moved the assetstore into S3. And since then there's been an almost constant stream of errors like this in the logs.
com.amazonaws.http.AmazonHttpClient @ Unable to execute HTTP request: Timeout waiting for connection from pool org.apache.http.conn.ConnectionPoolTimeoutException: Timeout waiting for connection from pool When that happened I set up a connection pool using the instructions in the DSpace 6 installation docs - https://wiki.duraspace.org/display/DSDOC6x/Installing+DSpace#InstallingDSpace-Externaldatabaseconnectionpool. And I set it up with what I thought were sufficiently high values for the maximum total connections (200) and maximum idle connections (50). But the new setup has been in place for a few days now, and we're still seeing connection pool timeouts on a daily basis. Even though the maximum total connections is set to 200, we never see near that many postgres processes at any given time. Is there some additional configuration to the JNDI Datasource that would help our situation? Or were there other things people did to improve the performance? Thanks, Nick On Wednesday, January 3, 2018 at 3:29:12 PM UTC-6, Mark H. Wood wrote: > > You might want to consider moving the pool out of DSpace's control into > the Servlet container -- see "Notes on PostgreSQL connection pooling with a > Tomcat JNDI resource" by Alan Orth elsewhere in this group. It would give > you access to more of the pool's parameters (for testing connections before > use, and the like) and also make it easy to use a newer driver. I've had > better luck with this arrangement. > > I believe that db.statementpool affects pooling of prepared statements > only. Unless you've adjusted PostgreSQL, the default on its end is to do > no statement pooling regardless of what the client requests. Like most > DBMS-centric webapp.s, DSpace can't operate without a connection pool. > -- All messages to this mailing list should adhere to the DuraSpace Code of Conduct: https://duraspace.org/about/policies/code-of-conduct/ --- You received this message because you are subscribed to the Google Groups "DSpace Technical Support" group. To unsubscribe from this group and stop receiving emails from it, send an email to dspace-tech+unsubscr...@googlegroups.com. To post to this group, send email to firstname.lastname@example.org. Visit this group at https://groups.google.com/group/dspace-tech. For more options, visit https://groups.google.com/d/optout.