Return-Path: X-Original-To: apmail-tomcat-users-archive@www.apache.org Delivered-To: apmail-tomcat-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 0A2A992FD for ; Thu, 8 Mar 2012 08:36:25 +0000 (UTC) Received: (qmail 19298 invoked by uid 500); 8 Mar 2012 08:35:56 -0000 Delivered-To: apmail-tomcat-users-archive@tomcat.apache.org Received: (qmail 16992 invoked by uid 500); 8 Mar 2012 08:35:42 -0000 Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Tomcat Users List" Delivered-To: mailing list users@tomcat.apache.org Received: (qmail 15875 invoked by uid 99); 8 Mar 2012 08:34:53 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 08 Mar 2012 08:34:53 +0000 X-ASF-Spam-Status: No, hits=1.7 required=5.0 tests=FREEMAIL_ENVFROM_END_DIGIT,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of amits.84@gmail.com designates 209.85.220.173 as permitted sender) Received: from [209.85.220.173] (HELO mail-vx0-f173.google.com) (209.85.220.173) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 08 Mar 2012 08:34:47 +0000 Received: by vcbfl11 with SMTP id fl11so231240vcb.18 for ; Thu, 08 Mar 2012 00:34:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=s2o4929m9dNwfuukKMlwDmbdOgXrKIZANiJzgyvuuZg=; b=kFhSR9HZ1stKslTw4Vj3CekHyznZW1hhGru1DAiI7CVfUmN996bJ0bixhnp9811yvY QdE2EDkaKz8YSOdWgDoidf2q9+jyHbCyePMydbqmhC+DBnv82BMAFNvnMtO5PxQ4Nsnq 7U7LmnMqZXu3YxXhnTjri3+1uPyn5fxHsP5mykuUmAM/Fb3+li2NaHBoUnd0AwRmeiAQ fgpsnhAVk4wApcHXm9Paiz5fSyllPlP/5saQx5diTzJj0W6H2qkJaUpQIDEmB1MOFZA7 2fnR2UJlR4MuamIUNlzz1NScMuZCCi+vWpXQXpCr8seK4JKx18qQqV2S5YtwtDmdZ5+O vYkw== Received: by 10.52.35.12 with SMTP id d12mr8321658vdj.99.1331195666316; Thu, 08 Mar 2012 00:34:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.1.129 with HTTP; Thu, 8 Mar 2012 00:34:06 -0800 (PST) In-Reply-To: <4F577D83.6040601@christopherschultz.net> References: <4F56212E.6010208@christopherschultz.net> <4F577D83.6040601@christopherschultz.net> From: amit shah Date: Thu, 8 Mar 2012 14:04:06 +0530 Message-ID: Subject: Re: JDBC Pool - Error handling during connection creation To: Tomcat Users List Content-Type: multipart/alternative; boundary=20cf30780aced13e2004bab7248a X-Virus-Checked: Checked by ClamAV on apache.org --20cf30780aced13e2004bab7248a Content-Type: text/plain; charset=ISO-8859-1 Comment below On Wed, Mar 7, 2012 at 8:53 PM, Christopher Schultz < chris@christopherschultz.net> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Amit, > > On 3/7/12 12:12 AM, amit shah wrote: > > I am using tomcat-jdbc.jar and tomcat-juli.jar from version > > 7.0.26. > > > >> I don't see any place in setupConnection where an exception is > >> swallowed, do you? > >> > >> > http://svn.apache.org/viewvc/tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/ConnectionPool.java?view=markup > > > >> > > Have a look at the public boolean validate(int > > validateAction,String sql) method in PooledConnection class line no > > - 445. > > > The validate method ignores any exception which is thrown while > > validating the connection or executing the initSQL query. > > If you have debug logging enabled, it will log the exception. So, > enable debug logging and try again. *shrug* > > > The createConnection() method in ConnectionPool class which calls > > the validate() method returns null in such a case and hence it > > leads to a null pointer exception in setupConnection method. > > > > Ignoring the exception in the validate() method may sound > > appropriate (not sure for what reason though) but my point is that > > it makes troubleshooting the issue a lot harder. > > Just turn on debug logging and you'll see the original exception. I > think in this case, the error is quite fatal so checking for null and > emitting some other error message would only be slightly more helpful > to you, but the effect would be the same. > I understand that turning the log level to debug will display the original exception. The point is in production environments the log level would be by default info and it would take a longer time to understand the root cause. In our case, we execute a SP as an initSQL query, so the reasons why the query fails would increase. Hence it would been easier if the validate() method throws the exception instead of ignoring it. Do you see any issues in throwing the exception right there? > > - -chris > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.17 (Darwin) > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk9XfYMACgkQ9CaO5/Lv0PBdqQCgjhbGeAQ2QU64XOrYP5VBEkF6 > VkoAoL6g5gMTaYpnHvj7HZDqWT6P+qcE > =AzPZ > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org > For additional commands, e-mail: users-help@tomcat.apache.org > > --20cf30780aced13e2004bab7248a--