[
https://issues.apache.org/jira/browse/FLINK-17545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17107578#comment-17107578
]
John Lonergan commented on FLINK-17545:
---------------------------------------
Been hit by further failures due to this class.
This time it is resource leakage problems in the close method - the close
method doesn't take effective action to make sure that all its resources get
closed.
A failure in one operation will lead to the rest of the close method being
skipped.
Similarly the open method also leaks resources in the same way.
---
More generally..
We can fix these issues with a PR. But note that there are other related
classes that have similar issues that I've not report yet.
I'm interested in how folk feel about the general level of QA going on.
> 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 FLINK-17544 for background to this scenario.
> Synchronisation in JDBCUpsertOutputFormat allows resources leaks.
> The close() method is synchronised with write() and flush() but not open.
> So if open() is a slow call (which in my case it occasionally is) then it may
> not be complete when close() is called.
> In this situation the open() method will eventually proceed to open resources
> such as database connections that will never be closed by the program.
> So 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.
> ie Just before open() completes it would need to synchonise and then check if
> close has already been called whilst open() was running.
> If so then open() should proceed to undo any resources it has just opened.
> One could perhaps argue that there's a problem with the state model if the
> framework might call close before open has completed; but I can imagine why
> this happens.
> However, the must therefore deal with the consequential complexity of this
> deal with the threading issues effectively.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
