[ https://issues.apache.org/jira/browse/ARTEMIS-2955?focusedWorklogId=506598&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-506598 ]
ASF GitHub Bot logged work on ARTEMIS-2955: ------------------------------------------- Author: ASF GitHub Bot Created on: 30/Oct/20 09:24 Start Date: 30/Oct/20 09:24 Worklog Time Spent: 10m Work Description: franz1981 commented on pull request #3308: URL: https://github.com/apache/activemq-artemis/pull/3308#issuecomment-719442315 HI @uomik! Sorry I've missed your first comment on > It seems – quite obviously – that open prepared statements keep the connection active and prevent them to appear on idle connection eviction runs We're talking about default pool configuration right? It means `maxTotal` is infinite, `testWhileIdle` is `false` and `poolPreparedStatements` is `true`. My expectations are: 1. if a page/large-message load would happen, the number of live connections could grow over `maxTotal` along with the related prepared statements. 2. Given that ``testWhileIdle` is `false`, there is no object evictor that would test these connections until borrowed again: that's the only chance to acknowledge a network connectivity loss (and evict the related prepared statements too) and try to replace the invalid connection with a new one (and some new pooled statements too) It means 2 things to me: 1. the number of available alive connections (+ prepared statements) will grow to accomodate the max thread pool size ie number of parallel pages/large msg requested and won't decrease until some of these be borrowed and ack as invalid 2. > The nodes randomly reboot themselves due to connection issues when renewing live locks This shouldn't happen using the latest master, see [ARTEMIS-2941 Improve JDBC HA connection resiliency](https://issues.apache.org/jira/browse/ARTEMIS-2941) -> are you using the latest master? ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking ------------------- Worklog Id: (was: 506598) Time Spent: 2h 10m (was: 2h) > commons-dbcp2 performance issue with Derby Embedded DBMS > -------------------------------------------------------- > > Key: ARTEMIS-2955 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2955 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker, Tests > Affects Versions: 2.16.0 > Reporter: Francesco Nigro > Assignee: Francesco Nigro > Priority: Major > Fix For: 2.16.0 > > Attachments: image-2020-10-20-09-08-45-390.png, > image-2020-10-20-09-10-10-644.png, pooling_off.svg, pooling_on.svg, > screenshot-1.png, screenshot-2.png > > Time Spent: 2h 10m > Remaining Estimate: 0h > > The test suite has shown an increase in duration of 30 minutes going from to > 2:30 to 3 hours: it seems related to integration paging tests running on > Embedded Derby with the changes of > [ARTEMIS-2823|https://issues.apache.org/jira/browse/ARTEMIS-2823]. > After some profiling sessions on > org/apache/activemq/artemis/tests/integration/paging/PagingTest.testQueueRemoveAll > it seems that using commons-dbcp2 with Embedded Derby isn't working as > expected: > !image-2020-10-20-09-08-45-390.png! > while, if we switch to > [EmbeddedDataSource|https://db.apache.org/derby/docs/10.13/publishedapi/org/apache/derby/jdbc/EmbeddedDataSource.html] > we have > !image-2020-10-20-09-10-10-644.png! > By not using commons-dbcp2 we get roughtly a ~10X improvement in performance: > it seems that commons-dbcp2 is forcing to setup from the ground the prepared > statement each time, while EmbeddedDataSource nope. Specifically it seems > related to Derby GenericActivationHolder. > I suggest to disable commons-dbcp2 for Derby and investigate if it could > happen in a real broker too. > -- This message was sent by Atlassian Jira (v8.3.4#803005)