[ 
https://issues.apache.org/jira/browse/ARTEMIS-2955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17217474#comment-17217474
 ] 

Mikko commented on ARTEMIS-2955:
--------------------------------

{quote}Probably we should check if the data source class used is the default 
one before setting both these default, I don't think "maxTotal" is available to 
other data source solutions as well.
{quote}
Yes for clarity that's true. When using other data sources, I was relying on 
the fact that you always have to supply at least the url, username and password 
as custom data source property to get it to work anyway. So deducted that just 
checking if any properties are given is enough.

> 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
>         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: 40m
>  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)

Reply via email to