You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Nick Williams <ni...@nicholaswilliams.net> on 2014/02/05 23:46:44 UTC
About the DriverManagerConnectionSource
Guys,
Currently, the JDBCAppender allows users to specify a mechanism for connecting to the database using one of three options:
- DataSourceConnectionSource: Looks up a JNDI data source
- FactoryMethodConnectionSource: User specifies a class and static method for retrieving connections
- DriverManagerConnectionSource: User specifies JDBC URL, username, password, etc. to manually connect directly from Log4j.
Here's the problem: connections really need to be pooled for Log4j to log efficiently. In fact, I'd go so far as to say it's a *requirement*. It will either be flaky (if using the same connection continuously) or horrendously slow (if reconnecting every time) without pooling.
DataSourceConnectionSource and FactoryMethodConnectionSource lend themselves naturally to pooling. We can simply tell the user, 1) the DataSource must be a pooled DataSource or performance will suffer greatly, and 2) The factory must be backed by a connection pool or performance will suffer greatly. At that point, it's out of our hands and left up to the user to pool it. I like this.
DriverManagerConnectionSource is a different story. Since Log4j connects directly using this approach, we're left with two options:
- Remove support for DriverManagerConnectionSource and force the user to supply a factory or DataSource. (This is my favorite option.)
- Add Commons DBCP and Commons Pooling as required dependencies when using DriverManagerConnectionSource, then update DriverManagerConnectionSource to also accept connection pool size, thresholds, maximums, minimums, test queries, etc. (I really, *REALLY* don't like this option.)
I'm looking for some input from the rest of y'all on which direction we should take, or if you can think of any other options.
Thanks,
Nick
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: About the DriverManagerConnectionSource
Posted by Nick Williams <ni...@nicholaswilliams.net>.
Okay. Absent any other feedback, I'm going to remove the DriverManagerConnectionSource.
N
On Feb 6, 2014, at 4:03 PM, Matt Sicker wrote:
> It'd be cleaner to just remove it. Perhaps we could include in log4j-samples a sort of rudimentary connection pool factory using dbcp?
>
>
> On 5 February 2014 18:07, Remko Popma <re...@gmail.com> wrote:
>
>
> On Thursday, February 6, 2014, Nick Williams <ni...@nicholaswilliams.net> wrote:
>
> On Feb 5, 2014, at 5:52 PM, Remko Popma wrote:
>
>>
>>
>> On Thursday, February 6, 2014, Nick Williams <ni...@nicholaswilliams.net> wrote:
>> Guys,
>>
>> Currently, the JDBCAppender allows users to specify a mechanism for connecting to the database using one of three options:
>>
>> - DataSourceConnectionSource: Looks up a JNDI data source
>> - FactoryMethodConnectionSource: User specifies a class and static method for retrieving connections
>> - DriverManagerConnectionSource: User specifies JDBC URL, username, password, etc. to manually connect directly from Log4j.
>>
>> Here's the problem: connections really need to be pooled for Log4j to log efficiently. In fact, I'd go so far as to say it's a *requirement*. It will either be flaky (if using the same connection continuously) or horrendously slow (if reconnecting every time) without pooling.
>>
>> DataSourceConnectionSource and FactoryMethodConnectionSource lend themselves naturally to pooling. We can simply tell the user, 1) the DataSource must be a pooled DataSource or performance will suffer greatly, and 2) The factory must be backed by a connection pool or performance will suffer greatly. At that point, it's out of our hands and left up to the user to pool it. I like this.
>>
>> DriverManagerConnectionSource is a different story. Since Log4j connects directly using this approach, we're left with two options:
>>
>> - Remove support for DriverManagerConnectionSource and force the user to supply a factory or DataSource. (This is my favorite option.)
>>
>> I'd be fine with this option. If our experience so far shows that we can't really support direct connections (that is, we don't have good solutions for user problems) then removing it is not unreasonable I think.
>>
>> - Add Commons DBCP and Commons Pooling as required dependencies when using DriverManagerConnectionSource, then update DriverManagerConnectionSource to also accept connection pool size, thresholds, maximums, minimums, test queries, etc. (I really, *REALLY* don't like this option.)
>>
>> If Commons DBCP can be set up as a pooled DataSource, then there is no need for us to also support its use as a DriverManagerConnectionSource, is there?
>>
>>
>> I'm looking for some input from the rest of y'all on which direction we should take, or if you can think of any other options.
>>
>>
>> One other option (or perhaps this is more a migration path issue) is to leave the DriverManagerConnectionSource there but mark it as deprecated/dangerous/broken. Emit an ominous warn status logger message for existing users, and in the docs clarify that this will be removed in a subsequent release because we can't support it.
>
> It would be rather illogical to deprecate a class and say it will be remove "later" when we haven't even gone GA yet.
>
> Some people are using beta-9 in production, and I was thinking to provide a migration path for them. But on second thought, simply removing is cleaner. If people want to upgrade they should use a pooled connection source. I'm fine with that.
>
>
> Nick
>
>
>
> --
> Matt Sicker <bo...@gmail.com>
Re: About the DriverManagerConnectionSource
Posted by Matt Sicker <bo...@gmail.com>.
It'd be cleaner to just remove it. Perhaps we could include in
log4j-samples a sort of rudimentary connection pool factory using dbcp?
On 5 February 2014 18:07, Remko Popma <re...@gmail.com> wrote:
>
>
> On Thursday, February 6, 2014, Nick Williams <
> nicholas@nicholaswilliams.net> wrote:
>
>>
>> On Feb 5, 2014, at 5:52 PM, Remko Popma wrote:
>>
>>
>>
>> On Thursday, February 6, 2014, Nick Williams <
>> nicholas@nicholaswilliams.net> wrote:
>>
>>> Guys,
>>>
>>> Currently, the JDBCAppender allows users to specify a mechanism for
>>> connecting to the database using one of three options:
>>>
>>> - DataSourceConnectionSource: Looks up a JNDI data source
>>> - FactoryMethodConnectionSource: User specifies a class and static
>>> method for retrieving connections
>>> - DriverManagerConnectionSource: User specifies JDBC URL, username,
>>> password, etc. to manually connect directly from Log4j.
>>>
>>> Here's the problem: connections really need to be pooled for Log4j to
>>> log efficiently. In fact, I'd go so far as to say it's a *requirement*. It
>>> will either be flaky (if using the same connection continuously) or
>>> horrendously slow (if reconnecting every time) without pooling.
>>>
>>> DataSourceConnectionSource and FactoryMethodConnectionSource lend
>>> themselves naturally to pooling. We can simply tell the user, 1) the
>>> DataSource must be a pooled DataSource or performance will suffer greatly,
>>> and 2) The factory must be backed by a connection pool or performance will
>>> suffer greatly. At that point, it's out of our hands and left up to the
>>> user to pool it. I like this.
>>>
>>> DriverManagerConnectionSource is a different story. Since Log4j connects
>>> directly using this approach, we're left with two options:
>>>
>>> - Remove support for DriverManagerConnectionSource and force the user to
>>> supply a factory or DataSource. (This is my favorite option.)
>>
>>
>> I'd be fine with this option. If our experience so far shows that we
>> can't really support direct connections (that is, we don't have good
>> solutions for user problems) then removing it is not unreasonable I think.
>>
>>
>>> - Add Commons DBCP and Commons Pooling as required dependencies when
>>> using DriverManagerConnectionSource, then update
>>> DriverManagerConnectionSource to also accept connection pool size,
>>> thresholds, maximums, minimums, test queries, etc. (I really, *REALLY*
>>> don't like this option.)
>>
>>
>> If Commons DBCP can be set up as a pooled DataSource, then there is no
>> need for us to also support its use as a DriverManagerConnectionSource,
>> is there?
>>
>>
>>> I'm looking for some input from the rest of y'all on which direction we
>>> should take, or if you can think of any other options.
>>
>>
>>
>> One other option (or perhaps this is more a migration path issue) is to
>> leave the DriverManagerConnectionSource there but mark it as
>> deprecated/dangerous/broken. Emit an ominous warn status logger message for
>> existing users, and in the docs clarify that this will be removed in a
>> subsequent release because we can't support it.
>>
>>
>> It would be rather illogical to deprecate a class and say it will be
>> remove "later" when we haven't even gone GA yet.
>>
>
> Some people are using beta-9 in production, and I was thinking to provide
> a migration path for them. But on second thought, simply removing is
> cleaner. If people want to upgrade they should use a pooled
> connection source. I'm fine with that.
>
>
>> Nick
>>
>
--
Matt Sicker <bo...@gmail.com>
Re: About the DriverManagerConnectionSource
Posted by Remko Popma <re...@gmail.com>.
On Thursday, February 6, 2014, Nick Williams <ni...@nicholaswilliams.net>
wrote:
>
> On Feb 5, 2014, at 5:52 PM, Remko Popma wrote:
>
>
>
> On Thursday, February 6, 2014, Nick Williams <
> nicholas@nicholaswilliams.net<javascript:_e(%7B%7D,'cvml','nicholas@nicholaswilliams.net');>>
> wrote:
>
>> Guys,
>>
>> Currently, the JDBCAppender allows users to specify a mechanism for
>> connecting to the database using one of three options:
>>
>> - DataSourceConnectionSource: Looks up a JNDI data source
>> - FactoryMethodConnectionSource: User specifies a class and static method
>> for retrieving connections
>> - DriverManagerConnectionSource: User specifies JDBC URL, username,
>> password, etc. to manually connect directly from Log4j.
>>
>> Here's the problem: connections really need to be pooled for Log4j to log
>> efficiently. In fact, I'd go so far as to say it's a *requirement*. It will
>> either be flaky (if using the same connection continuously) or horrendously
>> slow (if reconnecting every time) without pooling.
>>
>> DataSourceConnectionSource and FactoryMethodConnectionSource lend
>> themselves naturally to pooling. We can simply tell the user, 1) the
>> DataSource must be a pooled DataSource or performance will suffer greatly,
>> and 2) The factory must be backed by a connection pool or performance will
>> suffer greatly. At that point, it's out of our hands and left up to the
>> user to pool it. I like this.
>>
>> DriverManagerConnectionSource is a different story. Since Log4j connects
>> directly using this approach, we're left with two options:
>>
>> - Remove support for DriverManagerConnectionSource and force the user to
>> supply a factory or DataSource. (This is my favorite option.)
>
>
> I'd be fine with this option. If our experience so far shows that we can't
> really support direct connections (that is, we don't have good solutions
> for user problems) then removing it is not unreasonable I think.
>
>
>> - Add Commons DBCP and Commons Pooling as required dependencies when
>> using DriverManagerConnectionSource, then update
>> DriverManagerConnectionSource to also accept connection pool size,
>> thresholds, maximums, minimums, test queries, etc. (I really, *REALLY*
>> don't like this option.)
>
>
> If Commons DBCP can be set up as a pooled DataSource, then there is no
> need for us to also support its use as a DriverManagerConnectionSource,
> is there?
>
>
>> I'm looking for some input from the rest of y'all on which direction we
>> should take, or if you can think of any other options.
>
>
>
> One other option (or perhaps this is more a migration path issue) is to
> leave the DriverManagerConnectionSource there but mark it as
> deprecated/dangerous/broken. Emit an ominous warn status logger message for
> existing users, and in the docs clarify that this will be removed in a
> subsequent release because we can't support it.
>
>
> It would be rather illogical to deprecate a class and say it will be
> remove "later" when we haven't even gone GA yet.
>
Some people are using beta-9 in production, and I was thinking to provide a
migration path for them. But on second thought, simply removing is cleaner.
If people want to upgrade they should use a pooled connection source. I'm
fine with that.
> Nick
>
Re: About the DriverManagerConnectionSource
Posted by Nick Williams <ni...@nicholaswilliams.net>.
On Feb 5, 2014, at 5:52 PM, Remko Popma wrote:
>
>
> On Thursday, February 6, 2014, Nick Williams <ni...@nicholaswilliams.net> wrote:
> Guys,
>
> Currently, the JDBCAppender allows users to specify a mechanism for connecting to the database using one of three options:
>
> - DataSourceConnectionSource: Looks up a JNDI data source
> - FactoryMethodConnectionSource: User specifies a class and static method for retrieving connections
> - DriverManagerConnectionSource: User specifies JDBC URL, username, password, etc. to manually connect directly from Log4j.
>
> Here's the problem: connections really need to be pooled for Log4j to log efficiently. In fact, I'd go so far as to say it's a *requirement*. It will either be flaky (if using the same connection continuously) or horrendously slow (if reconnecting every time) without pooling.
>
> DataSourceConnectionSource and FactoryMethodConnectionSource lend themselves naturally to pooling. We can simply tell the user, 1) the DataSource must be a pooled DataSource or performance will suffer greatly, and 2) The factory must be backed by a connection pool or performance will suffer greatly. At that point, it's out of our hands and left up to the user to pool it. I like this.
>
> DriverManagerConnectionSource is a different story. Since Log4j connects directly using this approach, we're left with two options:
>
> - Remove support for DriverManagerConnectionSource and force the user to supply a factory or DataSource. (This is my favorite option.)
>
> I'd be fine with this option. If our experience so far shows that we can't really support direct connections (that is, we don't have good solutions for user problems) then removing it is not unreasonable I think.
>
> - Add Commons DBCP and Commons Pooling as required dependencies when using DriverManagerConnectionSource, then update DriverManagerConnectionSource to also accept connection pool size, thresholds, maximums, minimums, test queries, etc. (I really, *REALLY* don't like this option.)
>
> If Commons DBCP can be set up as a pooled DataSource, then there is no need for us to also support its use as a DriverManagerConnectionSource, is there?
>
>
> I'm looking for some input from the rest of y'all on which direction we should take, or if you can think of any other options.
>
>
> One other option (or perhaps this is more a migration path issue) is to leave the DriverManagerConnectionSource there but mark it as deprecated/dangerous/broken. Emit an ominous warn status logger message for existing users, and in the docs clarify that this will be removed in a subsequent release because we can't support it.
It would be rather illogical to deprecate a class and say it will be remove "later" when we haven't even gone GA yet.
Nick
Re: About the DriverManagerConnectionSource
Posted by Remko Popma <re...@gmail.com>.
On Thursday, February 6, 2014, Nick Williams <ni...@nicholaswilliams.net>
wrote:
> Guys,
>
> Currently, the JDBCAppender allows users to specify a mechanism for
> connecting to the database using one of three options:
>
> - DataSourceConnectionSource: Looks up a JNDI data source
> - FactoryMethodConnectionSource: User specifies a class and static method
> for retrieving connections
> - DriverManagerConnectionSource: User specifies JDBC URL, username,
> password, etc. to manually connect directly from Log4j.
>
> Here's the problem: connections really need to be pooled for Log4j to log
> efficiently. In fact, I'd go so far as to say it's a *requirement*. It will
> either be flaky (if using the same connection continuously) or horrendously
> slow (if reconnecting every time) without pooling.
>
> DataSourceConnectionSource and FactoryMethodConnectionSource lend
> themselves naturally to pooling. We can simply tell the user, 1) the
> DataSource must be a pooled DataSource or performance will suffer greatly,
> and 2) The factory must be backed by a connection pool or performance will
> suffer greatly. At that point, it's out of our hands and left up to the
> user to pool it. I like this.
>
> DriverManagerConnectionSource is a different story. Since Log4j connects
> directly using this approach, we're left with two options:
>
> - Remove support for DriverManagerConnectionSource and force the user to
> supply a factory or DataSource. (This is my favorite option.)
I'd be fine with this option. If our experience so far shows that we can't
really support direct connections (that is, we don't have good solutions
for user problems) then removing it is not unreasonable I think.
> - Add Commons DBCP and Commons Pooling as required dependencies when using
> DriverManagerConnectionSource, then update DriverManagerConnectionSource to
> also accept connection pool size, thresholds, maximums, minimums, test
> queries, etc. (I really, *REALLY* don't like this option.)
If Commons DBCP can be set up as a pooled DataSource, then there is no need
for us to also support its use as a DriverManagerConnectionSource, is there?
> I'm looking for some input from the rest of y'all on which direction we
> should take, or if you can think of any other options.
One other option (or perhaps this is more a migration path issue) is to
leave the DriverManagerConnectionSource there but mark it as
deprecated/dangerous/broken. Emit an ominous warn status logger message for
existing users, and in the docs clarify that this will be removed in a
subsequent release because we can't support it.
> Thanks,
>
> Nick
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org<javascript:;>
> For additional commands, e-mail: log4j-dev-help@logging.apache.org<javascript:;>
>
>
Re: About the DriverManagerConnectionSource
Posted by Matt Sicker <bo...@gmail.com>.
I think if we added a DBCP/CP dependency version, that should be a separate
or optional module/plugin. It seems like it'd be useful as a demonstration
for a connection source factory.
On 5 February 2014 16:46, Nick Williams <ni...@nicholaswilliams.net>wrote:
> Guys,
>
> Currently, the JDBCAppender allows users to specify a mechanism for
> connecting to the database using one of three options:
>
> - DataSourceConnectionSource: Looks up a JNDI data source
> - FactoryMethodConnectionSource: User specifies a class and static method
> for retrieving connections
> - DriverManagerConnectionSource: User specifies JDBC URL, username,
> password, etc. to manually connect directly from Log4j.
>
> Here's the problem: connections really need to be pooled for Log4j to log
> efficiently. In fact, I'd go so far as to say it's a *requirement*. It will
> either be flaky (if using the same connection continuously) or horrendously
> slow (if reconnecting every time) without pooling.
>
> DataSourceConnectionSource and FactoryMethodConnectionSource lend
> themselves naturally to pooling. We can simply tell the user, 1) the
> DataSource must be a pooled DataSource or performance will suffer greatly,
> and 2) The factory must be backed by a connection pool or performance will
> suffer greatly. At that point, it's out of our hands and left up to the
> user to pool it. I like this.
>
> DriverManagerConnectionSource is a different story. Since Log4j connects
> directly using this approach, we're left with two options:
>
> - Remove support for DriverManagerConnectionSource and force the user to
> supply a factory or DataSource. (This is my favorite option.)
> - Add Commons DBCP and Commons Pooling as required dependencies when using
> DriverManagerConnectionSource, then update DriverManagerConnectionSource to
> also accept connection pool size, thresholds, maximums, minimums, test
> queries, etc. (I really, *REALLY* don't like this option.)
>
> I'm looking for some input from the rest of y'all on which direction we
> should take, or if you can think of any other options.
>
> Thanks,
>
> Nick
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
--
Matt Sicker <bo...@gmail.com>