nifi-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Burgess <>
Subject Re: Additional configuration properties for DBCPConnectionPool
Date Fri, 23 Feb 2018 21:25:17 GMT

What version of NiFi are you using? As of 1.1.0 [1], you can specify a
Validation Query on the DBCPConnectionPool, this is used by DBCP to
validate that a connection is "good" before offering it to the client.
For idle/timed-out connections, the validation query should fail and
DBCP should attempt to get a new connection.

For the additional configuration, if a property cannot be added via
the JDBC URL, then it can be added as a user-defined property (as of
NiFi 1.2.0 [2]), the code calls dataSource.addConnectionProperty() for
each of the supplied key/value pairs. Please see the processor doc [3]
for more details.



On Fri, Feb 23, 2018 at 4:00 PM, Tim Zimmerman <> wrote:
> Without going into too much detail (unless it would be useful). I am facing
> an issue where long standing connections are eventually failing when
> SQLServer attempts to bulk insert a file from NAS (we are using
> integratedSecurity and the SQLServer is configured with kerberos
> authentication and delegation). The process does work but at some point the
> bulk insert is denied access to the file and it appears to be an issue with
> the kerberos ticket becoming stale.
> The solution seems to be to time out connections that have been idle for
> some time and allow the pool to reduce to zero connections. This forces a
> new connection and authorization when needed. The connection seems to work
> for as long as needed and after it is idle for some time it is removed from
> the pool.
> These additional configurations are available in the underlying
> DBCPConnectionPool but are not exposed through the service configuration. Is
> there a specific reason they have not been exposed? I have downloaded the
> source and made the changes myself but before I go any further I would like
> to make sure I am not being too clever for my own good.
> Also, if there is not a specific reason they have not been exposed, would
> this be something that would be considered for a future release?
> --
> Sent from:

View raw message