Return-Path: X-Original-To: apmail-logging-log4j-dev-archive@www.apache.org Delivered-To: apmail-logging-log4j-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id DD64A10303 for ; Thu, 6 Feb 2014 00:07:35 +0000 (UTC) Received: (qmail 87111 invoked by uid 500); 6 Feb 2014 00:07:35 -0000 Delivered-To: apmail-logging-log4j-dev-archive@logging.apache.org Received: (qmail 87036 invoked by uid 500); 6 Feb 2014 00:07:34 -0000 Mailing-List: contact log4j-dev-help@logging.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Help: List-Post: List-Id: "Log4J Developers List" Reply-To: "Log4J Developers List" Delivered-To: mailing list log4j-dev@logging.apache.org Received: (qmail 87028 invoked by uid 99); 6 Feb 2014 00:07:34 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 06 Feb 2014 00:07:34 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of remko.popma@gmail.com designates 209.85.219.52 as permitted sender) Received: from [209.85.219.52] (HELO mail-oa0-f52.google.com) (209.85.219.52) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 06 Feb 2014 00:07:30 +0000 Received: by mail-oa0-f52.google.com with SMTP id i4so1420399oah.25 for ; Wed, 05 Feb 2014 16:07:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=+pba8UVXFQpNb++BFTr7xPmt2Y7EGhN62WBfzNd0Snk=; b=mQ4N2PQXZeilsBLSUxJA3Wd6B7rmBGVrrDI8xPPEgC4tHet/lIFhC+K89F8AW8Zmwh lTLtJTSg8gDcn7fSxCboqZDkUYFrpf15e2ngIMleHl0JjRz9GAbw7Yj20LdS2PMU762j 9GjsCkomuOq5Usv7GLx0IBwgQjSfoaMdOtLHSgVETltFW+djEDWO92Y5ZNAPJpPE/IYV CQxZNul1NALGPrnC7mu+qKkW03UbRnPlP9R1TFKnYdzJ6xblZAUmEDJq0iA+YWhGVyAL wXq4jlbv+0iIqMg0ZzVTFeR6Sd2O1w+I+dNyAUL5k0MMXwsZLLzizMBwjxeWiKKbQfmo HWEA== MIME-Version: 1.0 X-Received: by 10.60.98.40 with SMTP id ef8mr3950421oeb.13.1391645229647; Wed, 05 Feb 2014 16:07:09 -0800 (PST) Received: by 10.76.113.175 with HTTP; Wed, 5 Feb 2014 16:07:09 -0800 (PST) In-Reply-To: References: <895079DA-3015-4F7C-8C5B-AA5FD045FBC9@nicholaswilliams.net> Date: Thu, 6 Feb 2014 09:07:09 +0900 Message-ID: Subject: Re: About the DriverManagerConnectionSource From: Remko Popma To: Log4J Developers List Content-Type: multipart/alternative; boundary=089e013a182291578904f1b1a771 X-Virus-Checked: Checked by ClamAV on apache.org --089e013a182291578904f1b1a771 Content-Type: text/plain; charset=ISO-8859-1 On Thursday, February 6, 2014, Nick Williams 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 > --089e013a182291578904f1b1a771 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thursday, February 6, 2014, Nick Williams <nicholas@nicholaswilliams.net> wrote:=

On Feb 5, 2014, at 5:52 P= M, Remko Popma wrote:



On Thursda= y, February 6, 2014, Nick Williams <nic= holas@nicholaswilliams.net> wrote:
Guys,

Currently, the JDBCAppender allows users to specify a mechanism for connect= ing to the database using one of three options:

- DataSourceConnectionSource: Looks up a JNDI data source
- FactoryMethodConnectionSource: User specifies a class and static method f= or retrieving connections
- DriverManagerConnectionSource: User specifies JDBC URL, username, passwor= d, etc. to manually connect directly from Log4j.

Here's the problem: connections really need to be pooled for Log4j to l= og efficiently. In fact, I'd go so far as to say it's a *requiremen= t*. It will either be flaky (if using the same connection continuously) or = horrendously slow (if reconnecting every time) without pooling.

DataSourceConnectionSource and FactoryMethodConnectionSource lend themselve= s 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 fact= ory 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 i= t. I like this.

DriverManagerConnectionSource is a different story. Since Log4j connects di= rectly using this approach, we're left with two options:

- Remove support for DriverManagerConnectionSource and force the user to su= pply 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 unrea= sonable I think.=A0
=A0
- 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 que= ries, etc. (I really, *REALLY* don't like this option.)
=A0
If Commons DBCP can be set up as a pooled=A0DataSource, = then there is no need for us to also support its use as a=A0DriverManagerConnectionSource,<= /span>=A0is=A0there?


I'm looking for some input from the rest of y'all on which directio= n we should take, or if you can think of any other options.


One other option (or perhaps this is more a= migration path issue)=A0is to leave the DriverManagerConnectionSource=A0there but mark it as deprecated/dangerous/broken. Emit an=A0ominou= s warn status logger=A0message for existing users, and in the docs clarify = that this will be removed in a subsequent release because we can't supp= ort it.=A0

It would be rather illogical to deprecate a cla= ss and say it will be remove "later" when we haven't even gon= e GA yet.

Some peo= ple are using beta-9 in production, and I was thinking to provide a migrati= on path for them. But on second thought, simply removing is cleaner. If peo= ple want to upgrade they should use a pooled connection=A0source. I'm f= ine with that.=A0


Nick
--089e013a182291578904f1b1a771--