activemq-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (Jira)" <>
Subject [jira] [Work logged] (ARTEMIS-2823) Improve JDBC connection management
Date Wed, 16 Sep 2020 06:34:00 GMT


ASF GitHub Bot logged work on ARTEMIS-2823:

                Author: ASF GitHub Bot
            Created on: 16/Sep/20 06:33
            Start Date: 16/Sep/20 06:33
    Worklog Time Spent: 10m 
      Work Description: uomik commented on pull request #3204:

   > Agree, but consider the simple case of a database upgrade ( ie a database restart):
a shared store implies a live and backup connected to it; the expectation during a database
upgrade would be that the live will go down (that's what is happening now) while the slave
should keep trying to became live (ie while now it just die).
   > Probably the backup behaviour of shared store ha should be different. It seems a separate
problem to me then this PR, just thinking loud.
   My time to completely agree :) I thought you were just referring to the behaviour of the
master. Backup should definitely behave differently on these occasions. 

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:

Issue Time Tracking

    Worklog Id:     (was: 484955)
    Time Spent: 5h 40m  (was: 5.5h)

> Improve JDBC connection management
> ----------------------------------
>                 Key: ARTEMIS-2823
>                 URL:
>             Project: ActiveMQ Artemis
>          Issue Type: Improvement
>          Components: Broker
>            Reporter: Mikko
>            Priority: Major
>          Time Spent: 5h 40m
>  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:
> [] 
> 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

View raw message