[
https://issues.apache.org/jira/browse/FLINK-17545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Lonergan updated FLINK-17545:
----------------------------------
Description:
See also
A related observation is synchronisation in JDBCUpsertOutputFormat and
resources leaks due to synchronisation issues.
The close() method is synchronised with write() and flush() but not open.
So my case where open() was slow and not yet complete when close() was called,
then the open() method would eventually proceed to open resources such as
database connections that will never be closed by the program.
If we are not going to synchronise open() with the other methods then an
alternative approach would be to have open() do a double check before returning.
Just before open() completes it would need to synchonise and then check if
close has already been whilst open() was running.
If so then open() should proceed to undo any resources it has just opened.
was:
Encountered a situation where I get an NPE from JDBCUpsertOutputFormat.
This occurs when close is called before open.
This happened because I had a sink where it had a final field of type
JDBCUpsertOutputFormat.
The open operation of my sink was slow (blocked on something else) and open on
the JDBCUpsertOutputFormat had not yet been called.
In the mean time the job was cancelled, which caused close on my sink to be
called, which then
called close on the JDBCUpsertOutputFormat .
This throws an NPE due to a lack of a guard on an internal field that is only
initialised in the JDBCUpsertOutputFormat open operation.
The close method already guards one potentially null value ..
{code:java}
if (this.scheduledFuture != null) {
{code}
But needs the additional guard below ...
{code:java}
if (jdbcWriter != null) // << THIS LINE NEEDED TO GUARD UNINITIALISE VAR
try {
jdbcWriter.close();
} catch (SQLException e) {
LOG.warn("Close JDBC writer failed.", e);
}
{code}
> Resource leak JDBCUpsertOutputFormat
> ------------------------------------
>
> Key: FLINK-17545
> URL: https://issues.apache.org/jira/browse/FLINK-17545
> Project: Flink
> Issue Type: Improvement
> Components: Connectors / JDBC
> Affects Versions: 1.10.0
> Reporter: John Lonergan
> Priority: Major
>
> See also
> A related observation is synchronisation in JDBCUpsertOutputFormat and
> resources leaks due to synchronisation issues.
> The close() method is synchronised with write() and flush() but not open.
> So my case where open() was slow and not yet complete when close() was
> called, then the open() method would eventually proceed to open resources
> such as database connections that will never be closed by the program.
> If we are not going to synchronise open() with the other methods then an
> alternative approach would be to have open() do a double check before
> returning.
> Just before open() completes it would need to synchonise and then check if
> close has already been whilst open() was running.
> If so then open() should proceed to undo any resources it has just opened.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
