You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@karaf.apache.org by "Leschke, Scott" <SL...@medline.com> on 2017/11/20 21:47:43 UTC
Pax JDBC DataSourceFactory connection pooling config
How does one configure the underlying connection pool when using Pax JDBC DataSourceFactory? I've been using this for a while and recently discovered it's not behaving as I intended. I'm using Hikari as my CP, and want to configure the following Hikari properties:
poolName
maximumPoolSize
minimumIdle
idleTimeout
maxLifetime
I've been prefixing each of these "hikari." (which I concluded was the proper way to do it some months ago), but it appears that Hikari is using defaults.
When I configure as follows,
hikari.poolName = Composite Enterprise Data
hikari.maximumPoolSize = 1
hikari.minimumIdle = 0
hikari.idleTimeout = 28800000
hikari.maxLifetime = 0
I immediately get 10 connections to the datastore, even before a connection is actually requested to run a query (Cisco Information Server (aka, Composite)).
This would be the default behavior if none of the above get used. I also tried prefixing with "pool." btw (which makes more sense to me), but get the same behavior.
Scott
Re: Pax JDBC DataSourceFactory connection pooling config
Posted by Timothy Ward <ti...@paremus.com>.
I agree that it sucks having to use Dictionary instances with Configuration Admin, but that’s not the recommended way to receive configuration. You’re much better off accepting a Map (or better yet a Component Property Type) into your DS component’s activate method (or activation field in R7).
The only people who should need to access the Configuration Admin service itself are people who are writing a configuration management agent. This is not a common thing as it means you’re building your own infrastructure - usually people use something like Felix File Install, Felix web console, Karaf, or some vendor product and don’t touch the “management side” of Config Admin in their applications at all.
Best Regards,
Tim
> On 22 Nov 2017, at 17:28, Leschke, Scott <SL...@medline.com> wrote:
>
> Hey Tim,
>
> You make a good point about obsolete vs. deprecated. Anyway, I was just looking at ConfigAdmin recently, I seem to recall seeing Dictionary exposed there. While I agree that changing something like that would be a breaking change, it seems to me that users would have the choice to continue to use R6 (or lower) versions of services if they needed to / felt so inclined. That’s kind of the point of OSGi, right, that you have that option?
>
> I’m kind of radical in my thinking in this regard, I’ll admit. Backwards compatibility is great, to a point. Sooner or later, if you want to bake a cake, you have to break some eggs. Oh well, one man’s opinion. Thanks for the response,
>
> Scott
>
> From: Timothy Ward [mailto:tim.ward@paremus.com]
> Sent: Wednesday, November 22, 2017 11:17 AM
> To: user@karaf.apache.org
> Subject: Re: Pax JDBC DataSourceFactory connection pooling config
>
> Hi Scott,
>
> The Dictionary type is actually not deprecated (although it is obsolete). Moving the OSGi core framework away from Dictionary would be a huge breaking change for users (rather than implementers), and simply isn’t going to happen. On the other hand there is really no need to interact with the OSGi framework at this level. In the general case, new specifications will attempt to make use of the best practices when they are made. These best practices may later turn out to have been wrong (c.f. Dictionary) but the alliance will avoid making breaking changes wherever possible in specification updates.
>
> I would honestly be surprised if you had regular (or even any) contact with the Dictionary type when using R7 specifications.
>
> Regards,
>
> Tim
>
>
> On 22 Nov 2017, at 17:06, Leschke, Scott <SLeschke@medline.com <ma...@medline.com>> wrote:
>
> Hi Tim,
>
> I’ve looked at this in the past a bit, unfortunately using it would require a more change on my part than just using the DSF with pooling. I’ll look at it again to see exactly what it would require as this pooling issue is a bit problematic.
>
> Regarding OSGi Release 7, I have a general question for you since you’re involved in the spec process. Is there any effort going toward not using deprecated Java APIs in service specs? I have a real issue with continuing to expose deprecated APIs. I was hoping the Java 9 would go so far as hide (not export) all deprecated classes but I don’t believe this has happened.
>
> The one that comes to mind is the use of java.util.Dictionary in numerous places. I’m sure there are others. Since OSGi supports runtime versioning, it would seem that replacing Dictionary with Map would be reasonable, as well as any other deprecated APIs that are exposed.
>
> Regards,
>
> Scott
>
> From: Timothy Ward [mailto:tim.ward@paremus.com <ma...@paremus.com>]
> Sent: Tuesday, November 21, 2017 4:01 AM
> To: user@karaf.apache.org <ma...@karaf.apache.org>
> Subject: Re: Pax JDBC DataSourceFactory connection pooling config
>
> Hi Scott,
>
> If you’re interested in using JDBC with pooling in an OSGi environment then I really would recommend looking at the Transaction Control service. This is a new specification coming in OSGi release 7, and it provides significant extensions to the DataSourceFactory model, including pooling, managed lifecycles for your database connection usage, standard configuration properties, and transaction support (both local and XA).
>
> The proposed reference implementation is available from Apache Aries, and implements all of the features from the specification draft. It also has a large number of tests for the various components, including local and XA JPA support (if that’s of interest).
>
> Regards,
>
> Tim
>
>
>
> On 20 Nov 2017, at 21:47, Leschke, Scott <SLeschke@medline.com <ma...@medline.com>> wrote:
>
> How does one configure the underlying connection pool when using Pax JDBC DataSourceFactory? I’ve been using this for a while and recently discovered it’s not behaving as I intended. I’m using Hikari as my CP, and want to configure the following Hikari properties:
>
> poolName
> maximumPoolSize
> minimumIdle
> idleTimeout
> maxLifetime
>
> I’ve been prefixing each of these “hikari.” (which I concluded was the proper way to do it some months ago), but it appears that Hikari is using defaults.
> When I configure as follows,
>
> hikari.poolName = Composite Enterprise Data
> hikari.maximumPoolSize = 1
> hikari.minimumIdle = 0
> hikari.idleTimeout = 28800000
> hikari.maxLifetime = 0
>
> I immediately get 10 connections to the datastore, even before a connection is actually requested to run a query (Cisco Information Server (aka, Composite)).
> This would be the default behavior if none of the above get used. I also tried prefixing with “pool.” btw (which makes more sense to me), but get the same behavior.
>
> Scott
RE: Pax JDBC DataSourceFactory connection pooling config
Posted by "Leschke, Scott" <SL...@medline.com>.
Hey Tim,
You make a good point about obsolete vs. deprecated. Anyway, I was just looking at ConfigAdmin recently, I seem to recall seeing Dictionary exposed there. While I agree that changing something like that would be a breaking change, it seems to me that users would have the choice to continue to use R6 (or lower) versions of services if they needed to / felt so inclined. That’s kind of the point of OSGi, right, that you have that option?
I’m kind of radical in my thinking in this regard, I’ll admit. Backwards compatibility is great, to a point. Sooner or later, if you want to bake a cake, you have to break some eggs. Oh well, one man’s opinion. Thanks for the response,
Scott
From: Timothy Ward [mailto:tim.ward@paremus.com]
Sent: Wednesday, November 22, 2017 11:17 AM
To: user@karaf.apache.org
Subject: Re: Pax JDBC DataSourceFactory connection pooling config
Hi Scott,
The Dictionary type is actually not deprecated (although it is obsolete). Moving the OSGi core framework away from Dictionary would be a huge breaking change for users (rather than implementers), and simply isn’t going to happen. On the other hand there is really no need to interact with the OSGi framework at this level. In the general case, new specifications will attempt to make use of the best practices when they are made. These best practices may later turn out to have been wrong (c.f. Dictionary) but the alliance will avoid making breaking changes wherever possible in specification updates.
I would honestly be surprised if you had regular (or even any) contact with the Dictionary type when using R7 specifications.
Regards,
Tim
On 22 Nov 2017, at 17:06, Leschke, Scott <SL...@medline.com>> wrote:
Hi Tim,
I’ve looked at this in the past a bit, unfortunately using it would require a more change on my part than just using the DSF with pooling. I’ll look at it again to see exactly what it would require as this pooling issue is a bit problematic.
Regarding OSGi Release 7, I have a general question for you since you’re involved in the spec process. Is there any effort going toward not using deprecated Java APIs in service specs? I have a real issue with continuing to expose deprecated APIs. I was hoping the Java 9 would go so far as hide (not export) all deprecated classes but I don’t believe this has happened.
The one that comes to mind is the use of java.util.Dictionary in numerous places. I’m sure there are others. Since OSGi supports runtime versioning, it would seem that replacing Dictionary with Map would be reasonable, as well as any other deprecated APIs that are exposed.
Regards,
Scott
From: Timothy Ward [mailto:tim.ward@paremus.com]
Sent: Tuesday, November 21, 2017 4:01 AM
To: user@karaf.apache.org<ma...@karaf.apache.org>
Subject: Re: Pax JDBC DataSourceFactory connection pooling config
Hi Scott,
If you’re interested in using JDBC with pooling in an OSGi environment then I really would recommend looking at the Transaction Control service. This is a new specification coming in OSGi release 7, and it provides significant extensions to the DataSourceFactory model, including pooling, managed lifecycles for your database connection usage, standard configuration properties, and transaction support (both local and XA).
The proposed reference implementation is available from Apache Aries, and implements all of the features from the specification draft. It also has a large number of tests for the various components, including local and XA JPA support (if that’s of interest).
Regards,
Tim
On 20 Nov 2017, at 21:47, Leschke, Scott <SL...@medline.com>> wrote:
How does one configure the underlying connection pool when using Pax JDBC DataSourceFactory? I’ve been using this for a while and recently discovered it’s not behaving as I intended. I’m using Hikari as my CP, and want to configure the following Hikari properties:
poolName
maximumPoolSize
minimumIdle
idleTimeout
maxLifetime
I’ve been prefixing each of these “hikari.” (which I concluded was the proper way to do it some months ago), but it appears that Hikari is using defaults.
When I configure as follows,
hikari.poolName = Composite Enterprise Data
hikari.maximumPoolSize = 1
hikari.minimumIdle = 0
hikari.idleTimeout = 28800000
hikari.maxLifetime = 0
I immediately get 10 connections to the datastore, even before a connection is actually requested to run a query (Cisco Information Server (aka, Composite)).
This would be the default behavior if none of the above get used. I also tried prefixing with “pool.” btw (which makes more sense to me), but get the same behavior.
Scott
Re: Pax JDBC DataSourceFactory connection pooling config
Posted by Timothy Ward <ti...@paremus.com>.
Hi Scott,
The Dictionary type is actually not deprecated (although it is obsolete). Moving the OSGi core framework away from Dictionary would be a huge breaking change for users (rather than implementers), and simply isn’t going to happen. On the other hand there is really no need to interact with the OSGi framework at this level. In the general case, new specifications will attempt to make use of the best practices when they are made. These best practices may later turn out to have been wrong (c.f. Dictionary) but the alliance will avoid making breaking changes wherever possible in specification updates.
I would honestly be surprised if you had regular (or even any) contact with the Dictionary type when using R7 specifications.
Regards,
Tim
> On 22 Nov 2017, at 17:06, Leschke, Scott <SL...@medline.com> wrote:
>
> Hi Tim,
>
> I’ve looked at this in the past a bit, unfortunately using it would require a more change on my part than just using the DSF with pooling. I’ll look at it again to see exactly what it would require as this pooling issue is a bit problematic.
>
> Regarding OSGi Release 7, I have a general question for you since you’re involved in the spec process. Is there any effort going toward not using deprecated Java APIs in service specs? I have a real issue with continuing to expose deprecated APIs. I was hoping the Java 9 would go so far as hide (not export) all deprecated classes but I don’t believe this has happened.
>
> The one that comes to mind is the use of java.util.Dictionary in numerous places. I’m sure there are others. Since OSGi supports runtime versioning, it would seem that replacing Dictionary with Map would be reasonable, as well as any other deprecated APIs that are exposed.
>
> Regards,
>
> Scott
>
> From: Timothy Ward [mailto:tim.ward@paremus.com <ma...@paremus.com>]
> Sent: Tuesday, November 21, 2017 4:01 AM
> To: user@karaf.apache.org <ma...@karaf.apache.org>
> Subject: Re: Pax JDBC DataSourceFactory connection pooling config
>
> Hi Scott,
>
> If you’re interested in using JDBC with pooling in an OSGi environment then I really would recommend looking at the Transaction Control service. This is a new specification coming in OSGi release 7, and it provides significant extensions to the DataSourceFactory model, including pooling, managed lifecycles for your database connection usage, standard configuration properties, and transaction support (both local and XA).
>
> The proposed reference implementation is available from Apache Aries, and implements all of the features from the specification draft. It also has a large number of tests for the various components, including local and XA JPA support (if that’s of interest).
>
> Regards,
>
> Tim
>
>
> On 20 Nov 2017, at 21:47, Leschke, Scott <SLeschke@medline.com <ma...@medline.com>> wrote:
>
> How does one configure the underlying connection pool when using Pax JDBC DataSourceFactory? I’ve been using this for a while and recently discovered it’s not behaving as I intended. I’m using Hikari as my CP, and want to configure the following Hikari properties:
>
> poolName
> maximumPoolSize
> minimumIdle
> idleTimeout
> maxLifetime
>
> I’ve been prefixing each of these “hikari.” (which I concluded was the proper way to do it some months ago), but it appears that Hikari is using defaults.
> When I configure as follows,
>
> hikari.poolName = Composite Enterprise Data
> hikari.maximumPoolSize = 1
> hikari.minimumIdle = 0
> hikari.idleTimeout = 28800000
> hikari.maxLifetime = 0
>
> I immediately get 10 connections to the datastore, even before a connection is actually requested to run a query (Cisco Information Server (aka, Composite)).
> This would be the default behavior if none of the above get used. I also tried prefixing with “pool.” btw (which makes more sense to me), but get the same behavior.
>
> Scott
RE: Pax JDBC DataSourceFactory connection pooling config
Posted by "Leschke, Scott" <SL...@medline.com>.
Hi Tim,
I’ve looked at this in the past a bit, unfortunately using it would require a more change on my part than just using the DSF with pooling. I’ll look at it again to see exactly what it would require as this pooling issue is a bit problematic.
Regarding OSGi Release 7, I have a general question for you since you’re involved in the spec process. Is there any effort going toward not using deprecated Java APIs in service specs? I have a real issue with continuing to expose deprecated APIs. I was hoping the Java 9 would go so far as hide (not export) all deprecated classes but I don’t believe this has happened.
The one that comes to mind is the use of java.util.Dictionary in numerous places. I’m sure there are others. Since OSGi supports runtime versioning, it would seem that replacing Dictionary with Map would be reasonable, as well as any other deprecated APIs that are exposed.
Regards,
Scott
From: Timothy Ward [mailto:tim.ward@paremus.com]
Sent: Tuesday, November 21, 2017 4:01 AM
To: user@karaf.apache.org
Subject: Re: Pax JDBC DataSourceFactory connection pooling config
Hi Scott,
If you’re interested in using JDBC with pooling in an OSGi environment then I really would recommend looking at the Transaction Control service. This is a new specification coming in OSGi release 7, and it provides significant extensions to the DataSourceFactory model, including pooling, managed lifecycles for your database connection usage, standard configuration properties, and transaction support (both local and XA).
The proposed reference implementation is available from Apache Aries, and implements all of the features from the specification draft. It also has a large number of tests for the various components, including local and XA JPA support (if that’s of interest).
Regards,
Tim
On 20 Nov 2017, at 21:47, Leschke, Scott <SL...@medline.com>> wrote:
How does one configure the underlying connection pool when using Pax JDBC DataSourceFactory? I’ve been using this for a while and recently discovered it’s not behaving as I intended. I’m using Hikari as my CP, and want to configure the following Hikari properties:
poolName
maximumPoolSize
minimumIdle
idleTimeout
maxLifetime
I’ve been prefixing each of these “hikari.” (which I concluded was the proper way to do it some months ago), but it appears that Hikari is using defaults.
When I configure as follows,
hikari.poolName = Composite Enterprise Data
hikari.maximumPoolSize = 1
hikari.minimumIdle = 0
hikari.idleTimeout = 28800000
hikari.maxLifetime = 0
I immediately get 10 connections to the datastore, even before a connection is actually requested to run a query (Cisco Information Server (aka, Composite)).
This would be the default behavior if none of the above get used. I also tried prefixing with “pool.” btw (which makes more sense to me), but get the same behavior.
Scott
Re: Pax JDBC DataSourceFactory connection pooling config
Posted by Timothy Ward <ti...@paremus.com>.
Hi Scott,
If you’re interested in using JDBC with pooling in an OSGi environment then I really would recommend looking at the Transaction Control service. This is a new specification coming in OSGi release 7, and it provides significant extensions to the DataSourceFactory model, including pooling, managed lifecycles for your database connection usage, standard configuration properties, and transaction support (both local and XA).
The proposed reference implementation is available from Apache Aries, and implements all of the features from the specification draft. It also has a large number of tests for the various components, including local and XA JPA support (if that’s of interest).
Regards,
Tim
> On 20 Nov 2017, at 21:47, Leschke, Scott <SL...@medline.com> wrote:
>
> How does one configure the underlying connection pool when using Pax JDBC DataSourceFactory? I’ve been using this for a while and recently discovered it’s not behaving as I intended. I’m using Hikari as my CP, and want to configure the following Hikari properties:
>
> poolName
> maximumPoolSize
> minimumIdle
> idleTimeout
> maxLifetime
>
> I’ve been prefixing each of these “hikari.” (which I concluded was the proper way to do it some months ago), but it appears that Hikari is using defaults.
> When I configure as follows,
>
> hikari.poolName = Composite Enterprise Data
> hikari.maximumPoolSize = 1
> hikari.minimumIdle = 0
> hikari.idleTimeout = 28800000
> hikari.maxLifetime = 0
>
> I immediately get 10 connections to the datastore, even before a connection is actually requested to run a query (Cisco Information Server (aka, Composite)).
> This would be the default behavior if none of the above get used. I also tried prefixing with “pool.” btw (which makes more sense to me), but get the same behavior.
>
> Scott
RE: Pax JDBC DataSourceFactory connection pooling config
Posted by "Leschke, Scott" <SL...@medline.com>.
Christian,
The code reference you sent along looks correct, at least based on my understanding of configuring Hikari, so perhaps there is some issue with Hikari itself? Will the next version of Pax JDBC use the newest version of Hikari (which I think is 2.7.3 or something like that?).
In my log file, I get the following, which would seem to indicate that the Hikari configuration properties aren’t being used. I previously thought that just the one config was being ignored but now I realize none are being used.
HikariDataSource | 143 - com.zaxxer.HikariCP - 2.4.1 | HikariPool-0 - is starting
Prior to using Pax, I was using Blueprint to create my datasources, during which time I would see the proper pool name “Composite Enterprise Data“ in the log.
Scott
From: cschneider111@gmail.com [mailto:cschneider111@gmail.com] On Behalf Of Christian Schneider
Sent: Tuesday, November 21, 2017 6:22 AM
To: user@karaf.apache.org
Subject: Re: Pax JDBC DataSourceFactory connection pooling config
When I look into the source I see that the hikari pooling checks for the prefix "hikari.". Maybe you can set a breakpoint there and check what it actually does.
See: https://github.com/ops4j/org.ops4j.pax.jdbc/blob/master/pax-jdbc-pool-hikaricp/src/main/java/org/ops4j/pax/jdbc/pool/hikaricp/impl/HikariPooledDataSourceFactory.java
Christian
2017-11-20 22:47 GMT+01:00 Leschke, Scott <SL...@medline.com>>:
How does one configure the underlying connection pool when using Pax JDBC DataSourceFactory? I’ve been using this for a while and recently discovered it’s not behaving as I intended. I’m using Hikari as my CP, and want to configure the following Hikari properties:
poolName
maximumPoolSize
minimumIdle
idleTimeout
maxLifetime
I’ve been prefixing each of these “hikari.” (which I concluded was the proper way to do it some months ago), but it appears that Hikari is using defaults.
When I configure as follows,
hikari.poolName = Composite Enterprise Data
hikari.maximumPoolSize = 1
hikari.minimumIdle = 0
hikari.idleTimeout = 28800000
hikari.maxLifetime = 0
I immediately get 10 connections to the datastore, even before a connection is actually requested to run a query (Cisco Information Server (aka, Composite)).
This would be the default behavior if none of the above get used. I also tried prefixing with “pool.” btw (which makes more sense to me), but get the same behavior.
Scott
--
--
Christian Schneider
http://www.liquid-reality.de<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.liquid-reality.de>
Computer Scientist
http://www.adobe.com
Re: Pax JDBC DataSourceFactory connection pooling config
Posted by Christian Schneider <ch...@die-schneider.net>.
When I look into the source I see that the hikari pooling checks for the
prefix "hikari.". Maybe you can set a breakpoint there and check what it
actually does.
See:
https://github.com/ops4j/org.ops4j.pax.jdbc/blob/master/pax-jdbc-pool-hikaricp/src/main/java/org/ops4j/pax/jdbc/pool/hikaricp/impl/HikariPooledDataSourceFactory.java
Christian
2017-11-20 22:47 GMT+01:00 Leschke, Scott <SL...@medline.com>:
> How does one configure the underlying connection pool when using Pax JDBC
> DataSourceFactory? I’ve been using this for a while and recently
> discovered it’s not behaving as I intended. I’m using Hikari as my CP, and
> want to configure the following Hikari properties:
>
>
>
> poolName
>
> maximumPoolSize
>
> minimumIdle
>
> idleTimeout
>
> maxLifetime
>
>
>
> I’ve been prefixing each of these “hikari.” (which I concluded was the
> proper way to do it some months ago), but it appears that Hikari is using
> defaults.
>
> When I configure as follows,
>
>
>
> hikari.poolName = Composite Enterprise Data
>
> hikari.maximumPoolSize = 1
>
> hikari.minimumIdle = 0
>
> hikari.idleTimeout = 28800000
>
> hikari.maxLifetime = 0
>
>
>
> I immediately get 10 connections to the datastore, even before a
> connection is actually requested to run a query (Cisco Information Server
> (aka, Composite)).
>
> This would be the default behavior if none of the above get used. I also
> tried prefixing with “pool.” btw (which makes more sense to me), but get
> the same behavior.
>
>
>
> Scott
>
--
--
Christian Schneider
http://www.liquid-reality.de
<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.liquid-reality.de>
Computer Scientist
http://www.adobe.com