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 dspace-tech@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.

Reply via email to