You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by amit shah <am...@gmail.com> on 2012/03/06 10:46:50 UTC
JDBC Pool - Error handling during connection creation
Hello,
I am using the tomcat jdbc pool independently in my application
and frequently I faced a NullPointerException with the below stack trace
null
at
org.apache.tomcat.jdbc.pool.ConnectionPool.setupConnection(ConnectionPool.java:276)
at
org.apache.tomcat.jdbc.pool.ConnectionPool.getConnection(ConnectionPool.java:180)
at
org.apache.tomcat.jdbc.pool.DataSourceProxy.getConnection(DataSourceProxy.java:124)
The root cause of the exception is suppressed by the jdbc pool code by
returning null from the validate() method. My point of raising this up is
that it becomes hard to troubleshoot such errors in production when the
actual exception is suppressed. The actual exception occurs while executing
the initSQL query or the validation query.
Shouldn't an exception be thrown right at the point where the error
occurred?
Thoughts/suggestions?
Thanks,
Amit.
Re: JDBC Pool - Error handling during connection creation
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Amit,
On 3/8/12 11:55 AM, Amit wrote:
> Enabling debug level would add some extra handling
>
> 1. We use slf4j & logback as our logging framework & tomcat uses
> jul logging. We would have to add jul-to-slf4j.jar to direct the
> jul messages to logback. This adds a performance overhead since
> the validation code & this class would be executed frequently.
>
> 2. Specially adding a logger in logback.xml for this particular
> class. We have multiple web applications which do not share the
> logback.xml currently.
>
> If the exception is not ignored and thrown right where it
> occurred, the stack trace would be enough to understand the root
> cause of the issue.
>
> [snip]
>
> I do not want to handle the exception. It would just help in
understanding the root cause in secs instead of mins since there could
many reasons why establishing a connection could fail. Seeing a null
pointer exception does not help at all.
So what you're saying is that you'd rather have someone here patch
Tomcat's code, then wait for another release, then upgrade all your
production systems and then see what the exception is, rather than
just enabling debug logging?
Now who's wasting time?
> I would appreciate if someone could detail on the benefits on
> having the code the way it is currently implemented i.e. why the
> exception is ignored instead of just throwing it there right away?
The method is not declared to throw any exceptions (except the
implicit RuntimeExceptions and Errors). Changing the API isn't
something that we like to do in stable releases unless it's absolutely
necessary. Filip would have to add his opinions on whether throwing
exceptions from validate is appropriate.
IMHO, debug logging is the right way to go in general. I don't think
the validate() method should throw anything, nor do I think that the
log level should be increased from debug to something higher.
- -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/
iEYEARECAAYFAk9ZDQEACgkQ9CaO5/Lv0PDTbgCguG7o2kPIOQliuFkuEby+gyFh
lFsAn0q6LrDPxSfE7C2wteVJr8waU34o
=hRYi
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: JDBC Pool - Error handling during connection creation
Posted by Daniel Mikusa <dm...@vmware.com>.
On Thu, 2012-03-08 at 08:55 -0800, Amit wrote:
>
>
>
> On 08-Mar-2012, at 6:37 PM, Daniel Mikusa <dm...@vmware.com> wrote:
>
> > On Thu, 2012-03-08 at 00:34 -0800, amit shah wrote:
> >> 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.
> >
> > Why not just set the log level to debug for that particular class? The
> > logging in that class seems to be minimal, even at debug level.
>
> Enabling debug level would add some extra handling
>
> 1. We use slf4j & logback as our logging framework & tomcat uses jul logging. We would have to add jul-to-slf4j.jar to direct the jul messages to logback. This adds a performance overhead since the validation code & this class would be executed frequently.
I would be a little surprised if it added significant overhead as there
is only a very small amount of logging in the PooledConnection class.
In addition, what logging does exist in that class seems to reside in
catch blocks. In other words, it doesn't seem like it would log
anything unless there is a problem.
That being said, I did not try this or do any performance testing on it,
so I can't really say exactly how it would affect performance. If
you've tested and the performance overhead is unacceptable then I'll
take your word for it.
>
> 2. Specially adding a logger in logback.xml for this particular class. We have multiple web applications which do not share the logback.xml currently.
>
> If the exception is not ignored and thrown right where it occurred, the stack trace would be enough to understand the root cause of the issue.
>
> >
> >>
> >> 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.
> >
> > I understand that you would like to get access to the exception, but can
> > you explain why you would want to do this? What would you do with the
> > exception? Where would you handle the exception?
> >
>
> I do not want to handle the exception. It would just help in understanding the root cause in secs instead of mins since there could many reasons why establishing a connection could fail. Seeing a null pointer exception does not help at all.
I get that the null pointer exception doesn't help. I've been there and
experienced that fun myself. However, it was just a quick matter of
enabling debug logging to see what is really happening.
Can't really say much more about this. It would seem that you have two
choices:
1.) Enable debug logging and see the exception.
2.) Make an adjustment to the source code and modify the exception
handling to fit your needs.
Dan
>
> I would appreciate if someone could detail on the benefits on having the code the way it is currently implemented i.e. why the exception is ignored instead of just throwing it there right away?
>
> > Dan
> >
> >>
> >> 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
> >>>
> >>>
> > B�KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB�� [��X��ܚX�KK[XZ[� \�\��][��X��ܚX�P �X�] �\X�K�ܙ�B��܈Y][ۘ[��[X[� �K[XZ[� \�\��Z[ �X�] �\X�K�ܙ�B�
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
Re: JDBC Pool - Error handling during connection creation
Posted by Amit <am...@gmail.com>.
On 08-Mar-2012, at 6:37 PM, Daniel Mikusa <dm...@vmware.com> wrote:
> On Thu, 2012-03-08 at 00:34 -0800, amit shah wrote:
>> 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.
>
> Why not just set the log level to debug for that particular class? The
> logging in that class seems to be minimal, even at debug level.
Enabling debug level would add some extra handling
1. We use slf4j & logback as our logging framework & tomcat uses jul logging. We would have to add jul-to-slf4j.jar to direct the jul messages to logback. This adds a performance overhead since the validation code & this class would be executed frequently.
2. Specially adding a logger in logback.xml for this particular class. We have multiple web applications which do not share the logback.xml currently.
If the exception is not ignored and thrown right where it occurred, the stack trace would be enough to understand the root cause of the issue.
>
>>
>> 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.
>
> I understand that you would like to get access to the exception, but can
> you explain why you would want to do this? What would you do with the
> exception? Where would you handle the exception?
>
I do not want to handle the exception. It would just help in understanding the root cause in secs instead of mins since there could many reasons why establishing a connection could fail. Seeing a null pointer exception does not help at all.
I would appreciate if someone could detail on the benefits on having the code the way it is currently implemented i.e. why the exception is ignored instead of just throwing it there right away?
> Dan
>
>>
>> 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
>>>
>>>
> B�KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB�� [��X��ܚX�KK[XZ[� \�\��][��X��ܚX�P �X�] �\X�K�ܙ�B��܈Y][ۘ[��[X[� �K[XZ[� \�\��Z[ �X�] �\X�K�ܙ�B�
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: JDBC Pool - Error handling during connection creation
Posted by Daniel Mikusa <dm...@vmware.com>.
On Thu, 2012-03-08 at 00:34 -0800, amit shah wrote:
> 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.
Why not just set the log level to debug for that particular class? The
logging in that class seems to be minimal, even at debug level.
>
> 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.
I understand that you would like to get access to the exception, but can
you explain why you would want to do this? What would you do with the
exception? Where would you handle the exception?
Dan
>
> 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
> >
> >
Re: JDBC Pool - Error handling during connection creation
Posted by amit shah <am...@gmail.com>.
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
>
>
Re: JDBC Pool - Error handling during connection creation
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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.
- -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
Re: JDBC Pool - Error handling during connection creation
Posted by amit shah <am...@gmail.com>.
Comments below.
Thanks,
Amit.
On Tue, Mar 6, 2012 at 8:07 PM, Christopher Schultz <
chris@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Amit,
>
> On 3/6/12 4:46 AM, amit shah wrote:
> > Hello, I am using the tomcat jdbc pool independently in my
> > application and frequently I faced a NullPointerException with the
> > below stack trace
> >
> > null at
> >
> org.apache.tomcat.jdbc.pool.ConnectionPool.setupConnection(ConnectionPool.java:276)
>
> What
> >
> exact version of Tomcat and/or the Tomcat pool are you using?
>
I am using tomcat-jdbc.jar and tomcat-juli.jar from version 7.0.26.
>
> > The root cause of the exception is suppressed by the jdbc pool code
> > by returning null from the validate() method. My point of raising
> > this up is that it becomes hard to troubleshoot such errors in
> > production when the actual exception is suppressed. The actual
> > exception occurs while executing the initSQL query or the
> > validation query.
> >
> > Shouldn't an exception be thrown right at the point where the
> > error occurred?
>
> 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.
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.
>
>
> - -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/
>
> iEYEARECAAYFAk9WIS4ACgkQ9CaO5/Lv0PAyFACfe/0jqpUzA1krhuxTFb/4sxJQ
> 46oAoJXV48dwC6IFy4f1dozhOc45Wo3R
> =ZHQa
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: JDBC Pool - Error handling during connection creation
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Amit,
On 3/6/12 4:46 AM, amit shah wrote:
> Hello, I am using the tomcat jdbc pool independently in my
> application and frequently I faced a NullPointerException with the
> below stack trace
>
> null at
> org.apache.tomcat.jdbc.pool.ConnectionPool.setupConnection(ConnectionPool.java:276)
What
>
exact version of Tomcat and/or the Tomcat pool are you using?
> The root cause of the exception is suppressed by the jdbc pool code
> by returning null from the validate() method. My point of raising
> this up is that it becomes hard to troubleshoot such errors in
> production when the actual exception is suppressed. The actual
> exception occurs while executing the initSQL query or the
> validation query.
>
> Shouldn't an exception be thrown right at the point where the
> error occurred?
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
- -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/
iEYEARECAAYFAk9WIS4ACgkQ9CaO5/Lv0PAyFACfe/0jqpUzA1krhuxTFb/4sxJQ
46oAoJXV48dwC6IFy4f1dozhOc45Wo3R
=ZHQa
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org