[
https://issues.apache.org/jira/browse/QPID-4837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13692080#comment-13692080
]
Rob Godfrey commented on QPID-4837:
-----------------------------------
I've made an initial checkin of the connection pool as an optional plugin (in
order to build you need to do ant build -Doptional=true ). The JDBCStore will
work without this plugin, or a plugin using an alternative ConnectionPool could
also be created.
In order to enable the connection pool, the following config needs to be added
within the <store> section of the virtualhost.xml:
{code:xml}
<pool>
<!-- type is required -->
<type>BONECP</type>
<!-- the following are optional -->
<minConnectionsPerPartition>5</minConnectionsPerPartition>
<maxConnectionsPerPartition>10</maxConnectionsPerPartition>
<partitionCount>4</partitionCount>
</pool>
{code}
I've not yet added the ability to configure this through the WebUI - I want to
make some changes to how the configuration is passed around first (moving from
using the XML Configuration as the master copy to using the VirtualHost
object). Hopefully these additional changes will still make it into 0.24.
> 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 library.
> 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-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
