[
https://issues.apache.org/jira/browse/HADOOP-16785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17010751#comment-17010751
]
Steve Loughran commented on HADOOP-16785:
-----------------------------------------
Looking at this, and wondering if there is more to do
FilterOutputStream.close does
{code}
public void close() throws IOException {
try (OutputStream ostream = out) {
flush();
}
}
{code}
.. which we fix.
But what if the codepath is something like
{code}
try (OutputStream ostream = new
FilterOutputStream(abfs.createFile("mydata.csv"))) {
ostream.write()
}
{code}
And its the write() which raises an exception.
In this situation, the FilterOutputStream.close() is the one which raises the
error, and as its the same in the write(), t-w-res will hit the same problem
In which case, the maybeThrowLastError() MUST always wrap the nested ex. This
guarantees no addSuppressed errors anywhere
Thoughts?
> Improve wasb and abfs resilience on double close() calls
> --------------------------------------------------------
>
> Key: HADOOP-16785
> URL: https://issues.apache.org/jira/browse/HADOOP-16785
> Project: Hadoop Common
> Issue Type: Sub-task
> Components: fs/azure
> Affects Versions: 3.2.1
> Reporter: Steve Loughran
> Assignee: Steve Loughran
> Priority: Major
> Fix For: 3.2.2
>
>
> # if you call write() after the NativeAzureFsOutputStream is closed it throws
> an NPE ... which isn't always caught by closeQuietly code. It needs to raise
> an IOE
> # abfs close ops can trigger failures in try-with-resources use
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
