[
https://issues.apache.org/jira/browse/FLUME-3049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denes Arvay updated FLUME-3049:
-------------------------------
Description:
see:
https://github.com/apache/flume/blob/trunk/flume-ng-auth/src/main/java/org/apache/flume/auth/UGIExecutor.java#L49
This has unexpected side effects as the callers try to catch the wrapped
exception, for example in {{BucketWriter.append()}}:
https://github.com/apache/flume/blob/trunk/flume-ng-sinks/flume-hdfs-sink/src/main/java/org/apache/flume/sink/hdfs/BucketWriter.java#L563
Here IOException is considered as non-transient failure thus the {{close()}} is
called, but when the original exception is wrapped into {{SecurityException}}
it doesn't trigger the close of the file.
Similarly in {{HDFSEventSink.process()}} method the `IOException` is handled in
a different way than any other exception. It might come from
{{BucketWriter.append()}} or {{BucketWriter.flush()}} for example, and both of
them invoke the hdfs call via a {{PrivilegedExecutor}} instance which might be
the problematic {{UGIExecutor}}.
The bottom line is that the contract in {{PrivilegedExecutor.execute()}} is
that they shouldn't change the exception thrown in the business logic - at
least it's not indicated in its signature in any way. The default
implementation ({{SimpleAuthenticator}}) behaves according to this.
I don't know the original intend behind this wrapping, [~jrufus] or
[~hshreedharan], do you happen to remember? (You were involved in the original
implementation in FLUME-2631)
Right now I don't see any problem in removing this and letting the original
exception to propagate as the {{org.apache.flume.auth.SecurityException}}
doesn't appear anywhere in the public interface.
was:
see:
https://github.com/apache/flume/blob/trunk/flume-ng-auth/src/main/java/org/apache/flume/auth/UGIExecutor.java#L49
This has unexpected side effects as the callers try to catch the wrapped
exception, for example in {{BucketWriter.append()}}:
https://github.com/apache/flume/blob/trunk/flume-ng-sinks/flume-hdfs-sink/src/main/java/org/apache/flume/sink/hdfs/BucketWriter.java#L563
I don't know the original intend behind this wrapping, [~jrufus] or
[~hshreedharan], do you happen to remember? (You were involved in the original
implementation in FLUME-2631)
Right now I don't see any problem in removing this and letting the original
exception to propagate as the {{org.apache.flume.auth.SecurityException}}
doesn't appear anywhere in the public interface.
> Wrapping the exception into SecurityException in UGIExecutor.execute hides
> the original one
> -------------------------------------------------------------------------------------------
>
> Key: FLUME-3049
> URL: https://issues.apache.org/jira/browse/FLUME-3049
> Project: Flume
> Issue Type: Bug
> Reporter: Denes Arvay
> Assignee: Denes Arvay
>
> see:
> https://github.com/apache/flume/blob/trunk/flume-ng-auth/src/main/java/org/apache/flume/auth/UGIExecutor.java#L49
> This has unexpected side effects as the callers try to catch the wrapped
> exception, for example in {{BucketWriter.append()}}:
> https://github.com/apache/flume/blob/trunk/flume-ng-sinks/flume-hdfs-sink/src/main/java/org/apache/flume/sink/hdfs/BucketWriter.java#L563
> Here IOException is considered as non-transient failure thus the {{close()}}
> is called, but when the original exception is wrapped into
> {{SecurityException}} it doesn't trigger the close of the file.
> Similarly in {{HDFSEventSink.process()}} method the `IOException` is handled
> in a different way than any other exception. It might come from
> {{BucketWriter.append()}} or {{BucketWriter.flush()}} for example, and both
> of them invoke the hdfs call via a {{PrivilegedExecutor}} instance which
> might be the problematic {{UGIExecutor}}.
> The bottom line is that the contract in {{PrivilegedExecutor.execute()}} is
> that they shouldn't change the exception thrown in the business logic - at
> least it's not indicated in its signature in any way. The default
> implementation ({{SimpleAuthenticator}}) behaves according to this.
> I don't know the original intend behind this wrapping, [~jrufus] or
> [~hshreedharan], do you happen to remember? (You were involved in the
> original implementation in FLUME-2631)
> Right now I don't see any problem in removing this and letting the original
> exception to propagate as the {{org.apache.flume.auth.SecurityException}}
> doesn't appear anywhere in the public interface.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
