qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (QPID-4837) JDBC store should use connection pooler
Date Thu, 27 Jun 2013 12:50:21 GMT

    [ https://issues.apache.org/jira/browse/QPID-4837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13694679#comment-13694679

ASF subversion and git services commented on QPID-4837:

Commit 1497335 from [~godfrer]
[ https://svn.apache.org/r1497335 ]

QPID-4837 : [Java Broker] add ability to use connection pool for JDBC store
> JDBC store should use connection pooler
> ---------------------------------------
>                 Key: QPID-4837
>                 URL: https://issues.apache.org/jira/browse/QPID-4837
>             Project: Qpid
>          Issue Type: Improvement
>          Components: Java Broker
>    Affects Versions: Future
>            Reporter: Michal Zerola
>            Priority: Minor
>             Fix For: 0.23
>         Attachments: qpid_jdbc_pooler.patch
> This JIRA discusses the possible improvement of the JDBC store as a follow-up of the
QPID-4763 issue. Since revision 1470549 the Java Qpid Broker can work with JDBC compliant
database store.
> However, our tests of the JDBC store (MySQL database was used as the backend) showed
that under the heavier load from the client (sending couple of 1000 persistence messages)
the broker looses connection to the database. Closer examination revealed that it was caused
by the exceeded number of incoming connections from the broker to the database server for
which the server was configured. The JDBC store was initiating the new connection many times,
instead of reusing already established one.
> We have extended the Java Broker for JDBC connection pool management using the BoneCP
> http://jolbox.com/
> This library manages the connections returned by the underlying JDBC driver, so available
connections are reused by the broker.
> Plugging the connection pooling library is quite straight-forward as you can see from
the attached patch. With the connection pooler the JDBC store works flawlessly (tested with
MySQL) in our testing configuration.
> If using the above library would not be applicable because of some reason, does it make
sense to implement the connection pooling management directly into the broker?
> Thank you,
> Michal

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org

View raw message