[
https://issues.apache.org/jira/browse/ARTEMIS-2823?focusedWorklogId=490702&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-490702
]
ASF GitHub Bot logged work on ARTEMIS-2823:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 25/Sep/20 12:33
Start Date: 25/Sep/20 12:33
Worklog Time Spent: 10m
Work Description: uomik commented on pull request #3204:
URL: https://github.com/apache/activemq-artemis/pull/3204#issuecomment-698902202
@franz1981
> I've just one concern looking at the default pool configuration: the
number of available JDBC connections in the pool and the behaviour when there
are none available.
>
> I see that paging + large messsages can use an unbounded number of
connections (it really depends by the amount of concurrent threads that perform
page/large msg streaming operations), the 2 journals requires 1 connections
each (binding + message journal) and the node manager requires 2 (the lease
lock + the node manager shared state) connections.
> That means that without paging or large messages a minimum of 2 + 2 = 4
database connections.
> The problem I see is paging and large messages: if the are too many some
of the other operations will hang, awaiting an available connection, that means
that probably we need to add the critical analyzer there or just let users
knows they can configure pool appropriately.
Getting back to this. We've lately opened our test cluster for "external"
clients, this has increased load and amount of transactions quite a lot. As a
result we've quite frequently seen an event where master restarts due to issues
with live locks. We are still using default settings for the pool and I'm
suspecting that this may actually be a result of DB connection starvation. I
will experiment with pool settings next week and will hopefully find something
to overcome this issue.
`2020-09-25 11:53:10,958 WARN [org.apache.activemq.artemis.core.server]
AMQ222010: Critical IO Error, shutting down the server. file=NULL,
message=Critical error while on live renew: java.lang.IllegalStateException:
live lock can't be renewed
at
org.apache.activemq.artemis.core.server.impl.jdbc.ActiveMQScheduledLeaseLock.run(ActiveMQScheduledLeaseLock.java:92)
[artemis-server-2.13.0.jar:2.13.0]
at
org.apache.activemq.artemis.core.server.ActiveMQScheduledComponent$2.run(ActiveMQScheduledComponent.java:306)
[artemis-commons-2.13.0.jar:2.13.0]
at
org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:42)
[artemis-commons-2.13.0.jar:2.13.0]
at
org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:31)
[artemis-commons-2.13.0.jar:2.13.0]
at
org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:65)
[artemis-commons-2.13.0.jar:2.13.0]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
[rt.jar:1.8.0_221]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[rt.jar:1.8.0_221]
at
org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)
[artemis-commons-2.13.0.jar:2.13.0]
2020-09-25 11:53:10,981 ERROR
[org.apache.activemq.artemis.core.server.impl.jdbc.ActiveMQScheduledLeaseLock]
live lock renew tooks 39255 ms, while is supposed to take <4000 ms`
----------------------------------------------------------------
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: 490702)
Time Spent: 10h 20m (was: 10h 10m)
> Improve JDBC connection management
> ----------------------------------
>
> Key: ARTEMIS-2823
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2823
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: Broker
> Reporter: Mikko
> Priority: Major
> Time Spent: 10h 20m
> Remaining Estimate: 0h
>
> I have a case where the whole clustering reliability and HA must rely on HA
> capabilities of clustered database, and running on top of application server
> is not an option.
> The current JDBC store implementation is rather bare bones on the connection
> management side. JDBC driver is used directly with no management layer. At
> startup, the broker just opens couple of direct connections to database and
> expects them to be available forever. This is something that cannot be
> expected in HA production environment. So, similarly to the discussion linked
> below, in our case we lose the db connection after one hour, and all the
> brokers need to be restared to get new connections:
> [http://activemq.2283324.n4.nabble.com/Artemis-does-not-reconnect-to-MySQL-after-connection-timeout-td4751956.html]
>
> This is something that could be resolved by simply using JDBC4 isValid
> checks, but proper connection handling and pooling through datasource would
> be preferrable.
> I have implemented a solution for this by using DBCP2 datasource. Our test
> cluster has been successfully running this forked version since the release
> of Artemis 2.13.0. I will prepare of pull request if this is seen to be
> something that can be useful.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
